This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: horrible disk thorughput on itanium
- From: Andrew Morton <akpm at zip dot com dot au>
- To: Ulrich Drepper <drepper at redhat dot com>
- Cc: Linus Torvalds <torvalds at transmeta dot com>, libc-alpha at sources dot redhat dot com
- Date: Fri, 07 Dec 2001 16:07:27 -0800
- Subject: Re: horrible disk thorughput on itanium
- References: <p73r8q86lpn.fsf@amdsim2.suse.de> <Pine.LNX.4.33.0112070710120.747-100000@mikeg.weiden.de> <9upmqm$7p4$1@penguin.transmeta.com> <u8k7vylu72.fsf@gromit.moeb>, <u8k7vylu72.fsf@gromit.moeb> <m3r8q67oqd.fsf@myware.mynet>
Ulrich Drepper wrote:
>
> Andreas Jaeger <aj@suse.de> writes:
>
> > This should be doable. We could easily implement libio/putc.c as
> > follows:
>
> That's stupid. Either you use putc_unlocked() as any sane person
> should in non-threaded code which then expands inline or you use
> __fsetlocking(FSETLOCKING_BYCALLER). Just because people cannot
> program correctly doesn't require the implementation to fix their
> problems.
I can take a perfectly good program written in 1995, run it
under current glibc and see it run like a crippled duck
purely because of changes in the C library. 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?
I don't, for example, see any of these new-fangled hacks in the
bison-1.30 source.
In answer to Geoff Keating's question, this program:
#include <stdio.h>
main()
{
int i;
for (i = 0; i < 100*1000*1000; i++)
putc(0, stdout);
exit(0);
}
when directed to /dev/null takes 7.5 seconds. But only 1.3 seconds
with putc_unlocked.