From owner-freebsd-hackers Mon Jan 22 02:21:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA27253 for hackers-outgoing; Mon, 22 Jan 1996 02:21:44 -0800 (PST) Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA27244 for ; Mon, 22 Jan 1996 02:21:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Root.COM (8.6.12/8.6.5) with SMTP id CAA14236; Mon, 22 Jan 1996 02:21:28 -0800 Message-Id: <199601221021.CAA14236@Root.COM> X-Authentication-Warning: implode.Root.COM: Host localhost didn't use HELO protocol To: "Amancio Hasty Jr." cc: Rob Mallory , freebsd-hackers@freefall.FreeBSD.org Subject: Re: stanford benchmark/usenix In-reply-to: Your message of "Mon, 22 Jan 1996 02:05:59 PST." <199601221005.CAA00415@rah.star-gate.com> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 22 Jan 1996 02:21:28 -0800 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >>>> David Greenman said: > > >Do we have pentium optimized bcopy and bzero ? > > > > > >Because some of the benchmarks could clearly benefit from them. > > > > After reading the Usenix paper on OS performance on Pentium machines, I'm > > inclined to add optimized code to our libc. Basically, get the processor typ > e > > (probably via sysctl) and use this to control which versions are called - > > similar to what I recently did with bzero in the kernel. > > ...This is fairly low priority, however, so won't likely happen for a few > > months. > >Gosh, do I see an open invitation or what ? 8) I didn't intend to suggest one, but if you or someone else decides to do this, bare in mind that there is definately many 'wrong ways' to do this. We don't want a plethora of "if (cpu_class == FOO)" type of things in libc as it reduces performance for small operations. I think the way to do it is to jump through a function vector that is initialized by default to a generic function. The function vector can then be changed to an optimized function for specific CPU types. This would happen at some convenient place before program startup, or perhaps in the generic function (which could, perhaps, be a stub whose sole purpose is to select the appropriate routine, or fall back to a generic one). I really don't want to get into this in more detail right now - I don't have the time and in the end it would be easier to just sit down and code it. If you think you know how to implement this correctly, then by all means, go for it! -DG David Greenman Core Team/Principal Architect, The FreeBSD Project