Why do you want libc to be 5 times slower than other libraries?

https://sourceware.org/ml/libc-help/2008-08/msg00007.html

by luismarques • 11 years ago

32 12 11 years ago

DiabloD3• 11 years ago

Wasn't this the post that eventually caused the eglibc fork that eventually became the primary glibc fork and merged back in?

exacube• 11 years ago

This post is really old (2008) and probably already resolved. Here is the jist of the optimization that this person provides:

memory and string functions in libc have poor performance because you are not using XMM registers and you have no efficient way of dealing with unaligned data. The most efficient way of copying data when source and destination have different alignments is to read aligned into XMM registers; shift and combine consecutive reads so that they fit the alignment of the destination; then write aligned

rodgerd• 11 years ago

Worth reading the followup: https://sourceware.org/ml/libc-help/2008-08/msg00009.html

dima55• 11 years ago

So some guy complains that a code path in libc is slow, but refuses to actually do anything to fix it. What's noteworthy here? Besides, this particular complaint is 7 years old. Poster: is this still an issue?

Qwertious• 11 years ago

Why are you automatically obliged to fix it JUST because you mentioned it? If they just didn't know in the first place then everyone would have benefited, and if they did then something was clearly seriously broken in that development community.

TimSchumann• 11 years ago

And from what I've heard, not that I would know, you've just described the rise of LLVM.

the_why_of_y• 11 years ago

Because in FLOSS, nobody is entitled to a pony.

Besides, the glibc developers did optimize memory and string operations, and the result was that people moaned because their buggy Adobe Flash players crashed because they were relying on particular implementation details of previous un-optimized implementations of memcpy that were explicitly not guaranteed by C99.

http://lwn.net/Articles/414467/

anon1385• 11 years ago

I think you must be unfamiliar with the glibc maintainers during that period. They were hostile to outside contributions, to put it mildly. The only way to fix it would have been to make a fork. Which is what actually happened in the end with eglibc.

A lot of the big distros dropped glibc and switched to eglibc because they didn't want to deal with the glibc maintainers and their refusal to fix things anymore: http://blog.aurel32.net/47

daurnimator• 11 years ago

For those that don't know, Agner's manuals ( http://agner.org/optimize/ ) are considered to be the #1 resource for learning and reference when programming optimized assembly

marinintim• 11 years ago

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.

Such free software!

wcoenen• 11 years ago

It's desirable to keep the ability to fix license issues as they pop up. But if the copyright of contributions is not assigned to a single entity, then it becomes nigh impossible to change the license of the project (e.g. to a newer version of the LGPL) because the permission of every single contributor would be required.

dagw• 11 years ago

You're free to take the GNU GLIBC apply your own patches and use that patched version to compile, use and ship your own software (assuming you comply with the GPL). What you are not free to do is require that your patches be included with the official distribution of GLIBC without agreeing to their terms.

Why do you want libc to be 5 times slower than other libraries?

Related Stories