From owner-freebsd-hackers  Tue Jan 23 06:44:44 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id GAA23963
          for hackers-outgoing; Tue, 23 Jan 1996 06:44:44 -0800 (PST)
Received: from elbe.desy.de (elbe.desy.de [131.169.82.208])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA23931
          for <hackers@freebsd.org>; Tue, 23 Jan 1996 06:44:32 -0800 (PST)
From: Lars Gerhard Kuehl <lars@elbe.desy.de>
Date: Tue, 23 Jan 96 15:37:44 +0100
Message-Id: <9601231437.AA12617@elbe.desy.de>
To: babkin@hq.icb.chel.su, davidg@Root.COM, curt@emergent.com
Subject: Re: stanford benchmark/usenix
Cc: hackers@freebsd.org
Sender: owner-hackers@freebsd.org
Precedence: bulk


Oh, what a strange discussion all around best benchmark hunting.
In particular there's absolutly no reason for any 'quick and
dirty' solution. First you can usually achieve a 2-5% performance
hit just by erasing the '2' from the compiler's optimization flag.
(Well, I concede, my expirience may depend on my special demands.)

For further processor dependent optimization, I can share only
davidg's opinion:

# inclined to add optimized code to our libc. Basically, get the processor type
# (probably via sysctl) and use this to control which versions are called -

!    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)

FreeBSD is not the other, slightly more common free OS, it should keep
nicely designed.

#    ...This is fairly low priority, however, so won't likely happen for a few
# months.

Good things need time. Nobody should forget, the results were not that bad!
Before weaving softlink library webs, it could be a better idea to
improve the mbuf scheme.

! the time and in the end it would be easier to just sit down and code it. If
			     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

An obviously very common experience...

	Lars