

Why do you want libc to be 5 times slower than other libraries? - luismarques
https://sourceware.org/ml/libc-help/2008-08/msg00007.html

======
exacube
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

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

------
rodgerd
Worth reading the followup: [https://sourceware.org/ml/libc-
help/2008-08/msg00009.html](https://sourceware.org/ml/libc-
help/2008-08/msg00009.html)

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

------
dima55
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
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.

~~~
the_why_of_y
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/](http://lwn.net/Articles/414467/)

------
marinintim
> 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!

~~~
dagw
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.

