This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: horrible disk thorughput on itanium


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]