[H-GEN] Sorcery

[Arjen Lentz]

[ Humbug *General* list - semi-serious discussions about Humbug and  ]
[ Unix-related topics.  Please observe the list's charter.           ]
[ Worthwhile understanding: http://www.humbug.org.au/netiquette.html ]

Hi Paul,

On Mon, 2002-03-04 at 13:46, Paul Gearon wrote:
> As far as the one-hammer-hits-all approach is concerned then having an
> optimised glibc could well help some apps, and it certainly won't hurt.
> 
> For many apps which have no specific bottlenecks (whether they be programs
> in /bin or your own code) then the more streamlined you can make each
> component of the overall system, the better your performance.  Obviously
> this doesn't count if your program is only spending 2% of it's time in
> glibc, with 90% of that in the kernel, but that doesn't apply to *every*
> process in the system.  (does it?  :-)

I'm afraid glibc needs a serious validation test suite before I'd be
comfortable having optimisation done on it.

I know that at MySQL AB, we consistently have to apply quite a number of
patches to glibc in order to get a solid binary compile for MySQL
Server. That's just source bugs in glibc. There are also compiler
dependent problems, and we all know optimisers can do nasty things too.
It all comes down to the same thing: how reliable is the resulting code?


Regards,
Arjen.

-- 
MySQL Training in Brisbane: 18-22 March, http://www.mysql.com/training/
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /    Mr. Arjen G. Lentz <arjen at mysql.com>
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB, Technical Writer, Trainer
/_/  /_/\_, /___/\___\_\___/   Brisbane, QLD Australia
       <___/   www.mysql.com


--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.