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

by luismarqueson 6/26/2015, 5:49:25 AM with 6 comments
  • by exacubeon 6/26/2015, 6:39:23 AM

    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

  • by daurnimatoron 6/26/2015, 7:10:57 AM

    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

  • by rodgerdon 6/26/2015, 7:00:25 AM

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

  • by DiabloD3on 6/26/2015, 6:36:18 AM

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

  • by dima55on 6/26/2015, 7:08:36 AM

    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?

  • by marinintimon 6/26/2015, 7:50:40 AM

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