From owner-freebsd-hackers  Mon Jan 22 05:03:09 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id FAA09240
          for hackers-outgoing; Mon, 22 Jan 1996 05:03:09 -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 FAA09231
          for <hackers@freebsd.org>; Mon, 22 Jan 1996 05:02:58 -0800 (PST)
Received: (from nerv@localhost) by nixpbe.pdb.sni.de (8.6.12/8.6.12) id OAA11833 for hackers@freebsd.org; Mon, 22 Jan 1996 14:02:49 +0100
Message-Id: <199601221302.OAA11833@nixpbe.pdb.sni.de>
Subject: Re: stanford benchmark/usenix
To: davidg@Root.COM
Date: Mon, 22 Jan 96 13:58:56 MET
From: Greg Lehey <lehey.pad@sni.de>
Cc: hackers@freebsd.org (Hackers; FreeBSD)
In-Reply-To: <199601221256.EAA14695@Root.COM>; from "David Greenman" at Jan 22, 96 4:56 am
X-Mailer: xmail 2.4 (based on ELM 2.2 PL16)
Sender: owner-hackers@freebsd.org
Precedence: bulk

> 
> >>    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?
> 
>    Certainly that's another way to do it, but it can be confusing to have lots
> of different libraries around. I suppose you'd handle this by using a symlink
> to point to the appropriately optimized version...and of course all of the
> versions have to at least run on all of the processors (otherwise hardware
> upgrades become very difficult and confusing (and bug-report generating!).

Yes, I thought of that.  The alterneative of being able to run the
versions on all processors rather defeats the advantage: I had thought
of a part of the system startup that checks the processor type and
puts in the correct hard links (symlinks are slower) before any
program gets started.  It would probably be a good idea to have an
emergency program which reinstated the generic libraries, too.

>    I switch CPUs around enough here that it would be a small problem for me
> personally, but I suppose it wouldn't be a problem for most people.

Most people don't switch CPUs, so they wouldn't have the problem.  But
certainly it needs a little care in the implementation.

Greg