This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.
Re: Why do you want libc to be 5 times slower than other libraries?
- From: "Ryan S. Arnold" <rsa at us dot ibm dot com>
- To: Agner Fog <agner at agner dot org>
- Cc: libc-help at sourceware dot org, Roland McGrath <roland at redhat dot com>
- Date: Tue, 05 Aug 2008 11:52:34 -0500
- Subject: Re: Why do you want libc to be 5 times slower than other libraries?
- Organization: IBM
- References: <4892AB88.9040905@agner.org> <489812AA.6070609@agner.org>
- Reply-to: rsa at us dot ibm dot com
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 contamination. 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 > > (www.agner.org/optimize/). 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, etc. 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: http://sourceware.org/ml/libc-alpha/2007-01/msg00025.html http://sourceware.org/ml/libc-alpha/2007-02/msg00022.html http://sourceware.org/ml/libc-alpha/2007-08/msg00051.html http://sourceware.org/ml/libc-alpha/2008-02/msg00045.html 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 routines? 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 appropriate. 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. Regards, Ryan S. Arnold IBM Linux Technology Center