Date: Thu, 20 Dec 2001 23:29:48 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Anthony Atkielski <anthony@freebie.atkielski.com> Cc: Gilbert Gong <ggong@cal.alumni.berkeley.edu>, advocacy@FreeBSD.org, Jeremiah Gowdy <jeremiah@sherline.com> Subject: Re: Microsoft Advocacy? Message-ID: <XFMail.011220232948.jhb@FreeBSD.org> In-Reply-To: <033001c189d0$4e0703d0$0a00000a@atkielski.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21-Dec-01 Anthony Atkielski wrote: > Thanks for the references; I've added the books to my wish list, and I'll > look at the code. > > One thing I wonder: If performance is so important that a few hundred clock > cycles matter, why is the code written in C? Because the asm the code generates is only few instructions longer (about 10 cycles or so on x86) with the benefit of working on several architectures with only needing each arch to implement 4 atomic operations (IIRC): atomic_cmpset_acq_ptr(), atomic_store_rel_ptr(), atomic_clear_ptr(), and atomic_set_ptr(). It makes the code much more maintainable. Especially considering that 5.0 so far has added SMP support on the Alpha platform, and new ports for sparc64 and ia64 (and possibly x86-64 and ppc by the time 5.0 is released). Making spin mutexes only perform critcal section enter/exits (i.e. disable preemption adn interrupts and then enable them again) is a simple change in some C code that is all of about 10 or so changed lines and affects all spin mutexes in the system. IOW, it's a very simple way to gain some extra performance on UP systems. It doesn't complicate the code very much at all. If desired, the system is setup so that the mutex operations can be written completely in assembler. However, gcc is intelligent enough and has decent enough inline assembly support that the C code it generates is very efficient for this task, all things considered. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011220232948.jhb>