Date: Fri, 7 May 2004 10:39:09 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Brad Knowles <brad.knowles@skynet.be> Cc: John Baldwin <jhb@FreeBSD.org> Subject: Re: 4.7 vs 5.2.1 SMP/UP bridging performance Message-ID: <Pine.NEB.3.96L.1040507103655.90990E-100000@fledge.watson.org> In-Reply-To: <p0600202dbcc0e2264360@[10.0.1.2]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 7 May 2004, Brad Knowles wrote: > At 10:55 PM -0400 2004/05/06, Robert Watson wrote: > > > On occasion, I've had conversations with Peter Wemm about providing HAL > > modules with optimized versions of various common routines for specific > > hardware platforms. However, that would require us to make a trade-off > > between the performance benefits of inlining and the performance benefits > > of a HAL module... > > I'm confused. Couldn't you just do this sort of stuff as > conditional macros, which would have both benefits? Well, the goal of introducing HAL modules would be that you don't have to recompile the kernel in order to perform local hardware-specific optimization of low level routines. I.e., you could substitute faster implementations of zeroing, synchronization, certain math routines, etc based on the CPU discovered at run-time. While you can have switch statements, etc, it's faster just to relink the kernel to use the better implementation for the available CPU. However, if you do that, you still end up with the function call cost, which might well out-weight the benefits of specialization. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040507103655.90990E-100000>