From owner-freebsd-hackers Mon Jan 22 04:26:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA07068 for hackers-outgoing; Mon, 22 Jan 1996 04:26:00 -0800 (PST) Received: from nixpbe.pdb.sni.de (mail.sni.de [192.109.2.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA07016 for ; Mon, 22 Jan 1996 04:25:08 -0800 (PST) Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id NAA10132 for hackers@freebsd.org; Mon, 22 Jan 1996 13:24:45 +0100 Message-Id: <199601221224.NAA10132@nixpbe.pdb.sni.de> Subject: Re: stanford benchmark/usenix To: davidg@Root.COM Date: Mon, 22 Jan 96 13:20:51 MET From: Greg Lehey Cc: hackers@freebsd.org (Hackers; FreeBSD) In-Reply-To: <199601221021.CAA14236@Root.COM>; from "David Greenman" at Jan 22, 96 2:21 am X-Mailer: xmail 2.4 (based on ELM 2.2 PL16) 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! Wouldn't it make more sense to have separate libraries for each processor type, and to install the appropriate versions? Greg