Date: Tue, 23 Jan 96 15:37:44 +0100 From: Lars Gerhard Kuehl <lars@elbe.desy.de> To: babkin@hq.icb.chel.su, davidg@Root.COM, curt@emergent.com Cc: hackers@freebsd.org Subject: Re: stanford benchmark/usenix Message-ID: <9601231437.AA12617@elbe.desy.de>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9601231437.AA12617>