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


X-PMC-CI-e-mail-id: 17220 

>Until we tweaked it to work around glibc, stdio output of CPP 3.1 was
>taking as much as 70% of runtime.  The tweaks have got it down to "as
>much as 40%", which is still pretty appalling.


I noticed that there is a simple-minded benchmark program called
Bonnie.
This is a program that checks for disk I/O.
One of the test is to use character I/O for reading and
writing to disk files. This is supposed to check 
the performance of C library, I think.

As is already discussed, due to the locking,
the character I/O is significantly slow.
I noticed the slowness when I ran Bonnie under linux.
(The original aim was testing SCSI adaptor driver.)

I dug around and found out about the reentrant stdio routines.

As many have pointed out, I doubt if many average programmers
are aware that the slow (and thread-safe) I/O routines are used
with glibc unless the programmer takes some action.

I didn't know about it until I ran Bonnie and noticed the rather
abnormal figures. I thought it was odd even considering the normal
overhead, and then checked the headers and investigated and became
aware of the reentrant stdio routines.

Unless we take some measures, be it technical or public-relation one
(meaning documentation, and/or notices to various mailing lists and/or
newsgroups pointing to a permanent web page or something),
end users may suffer from programs that use the slow (and safe)
routines unnecessarily.

It certainly is a bad public relation topic.







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