This is the mail archive of the 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: Why do you want libc to be 5 times slower than other libraries?

On Tue, 2008-08-05 at 10:43 +0200, Agner Fog wrote:
> I have found that libc is up to 5 times slower than the best function 
> libraries for important memory and string functions. This was documented 
> in my last mail (included below). I also told how to improve it. But 
> nobody seems to care!?

People care but volunteers work at volunteer pace.

> I think that this topic belongs in the libc-alpha mailing list, but the 
> moderator rejected my mail and told me to send it to libc-help instead. 
> And here nobody replies.

ïYour email to libc-alpha was rejected because the libc-alpha mailing
list isn't a discussion list for covering the process of glibc
bug/enhancement submissions (that is what bugzilla and/or libc-help are
for).  Regarding contribution:

     a.) GLIBC is a GPL licensed project where the copyright for the
code in question has been assigned to the Free Software Foundation.  All
code that is contributed must be copyright assigned to the Free Software
Foundation.  This means that, regardless of the license of the reference
code, we can not use 'open source' code from other projects unless it
has been explicitly copyright assigned to the FSF.

     b.) Many GLIBC develops won't even look at other code for fear of

     c.) The principles of free software collaboration generally follow
the 'scratch an itch' pattern.  Many of us are volunteers or we're
professionals who're tasked with concentrating on certain aspects of
GLIBC or specific architectures.  It is a very limited contribution (in
our eyes) to offer up a TODO list without following up with the time to
do the work, prove it, and contribute it while following the proper
process that makes it possible for us to accept the contribution.

> I know that libc-help is for questions only, so here is my question:

The ïlibc-help mailing list is for a lot of things, not just questions.
It is a place to develop ideas, vet patches, learn the development
process, refine patches, etc.

> Are you so happy that libc is much slower than other libraries that you 
> don't want to make it faster?

Performance improvements have been actively pursued for some time,
especially by the companies who produce the architectures in question.
Please engage this mailing list and the particular developers indicated
below if you can identify problems with the current routines.

> Agner Fog wrote:
> > I am doing research on optimization of microprocessors and compilers. 
> > Some of you probably know my optimization manuals 
> > (

Regarding optimization of critical memory routines; There are several
questions you've left unanswered.  This is quite a hefty topic to drop
on us.

     a.) There is already a framework for optimizations.  All there is
to do is put optimal assembly code into sysdeps/cpu/cputype
subdirectories, e.g.: sysdeps/i386/i686/memcpy.S,
sysdeps/x86_64/mempcpy.S, sysdeps/powerpc/powerpc64/power6/memcpy.S,

     b.) You didn't CC any of the developers at AMD or Intel who've
already worked on such optimizations, e.g. Evandro Menezes, Michael
Meissner, H.J. Lu, Harsha Jagasia, et al.

     c.) There are already implementations by AMD and Intel's own
programmers that're actively being developed:

     d.) Your email didn't indicate how you gathered your data or
whether you verified that what you were testing is an optimized version
of the code for the processor in question.  It is up to the Linux OS
distributor to decide whether to compile and ship a CPU optimized
library for a particular CPU or CPU subtype with their distribution.
Did you compile your own versions of GLIBC for your tests?  Are you sure
you distribution isn't using the default (non-cpu specific) string

     e.) Any optimization of critical routines has to take into account
many factors regarding the data being processed.  Of concern is not only
aligned and unaligned data, but also data length, e.g.

        short-aligned, short-unaligned, long-aligned, long-unaligned

     f.) You'll have to get consensus amongst the concerned parties (and
with the maintainer) that the trade-offs you're suggesting are
People will work with you but you have to realize that you'll need to
work with the existing developers from AMD and Intel to improve the
performance of the existing string functions.

Ryan S. Arnold
IBM Linux Technology Center

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