horrible disk thorughput on itanium
Paul Eggert
eggert@twinsun.com
Fri Dec 7 20:10:00 GMT 2001
> Date: Fri, 07 Dec 2001 16:07:27 -0800
> From: Andrew Morton <akpm@zip.com.au>
> Are you saying that all existing code needs to be edited,
> recompiled, retested and redistributed, just so it can perform as
> well as it used to?
Naah. You can just run the traditional code on Solaris instead, as
the Solaris putc_unlocked approach doesn't cripple any ducks. :-)
> I don't, for example, see any of these new-fangled hacks in the
> bison-1.30 source.
Bison is a special case. A Bison-generated parser must not use
putc_unlocked by default, since the parser might be used in a
multithreaded application. Conversely, Bison itself can be slow, and
not too many people will care. So I don't think it's all that bad if
Bison doesn't worry about putc_unlocked.
It's a different story with other applications, though -- the apps for
which performance actually matters.
A few performance-oriented apps already have workarounds for this
glibc misfeature. I just added such a workaround to GNU diffutils,
for example. But I'm afraid that most GNU apps just poke along in
slow mode when linked with glibc.
More information about the Libc-alpha
mailing list