Glibc change exposing bugs [LWN.net]

Glibc change exposing bugs

Posted Nov 11, 2010 0:26 UTC (Thu) by jwb (guest, #15467)
In reply to: Glibc change exposing bugs by patrick_g
Parent article: Glibc change exposing bugs

Then it makes sense that he didn't see a speedup because the patch claims 1x speeds on Core i7. The improvement is seen on Atom and Core2.

(Log in to post comments)

Glibc change exposing bugs

Posted Nov 11, 2010 5:01 UTC (Thu) by nicooo (guest, #69134) [Link]

This change is starting to sound more and more pointless.

Glibc change exposing bugs

Posted Nov 11, 2010 6:54 UTC (Thu) by madscientist (subscriber, #16861) [Link]

Well, I have a core2 and I'd LOVE to get 4x speed improvement on memcpy(), which is probably the single most widely used function in all of C programming.

So it doesn't sound useless to me.

Glibc change exposing bugs

Posted Nov 11, 2010 9:42 UTC (Thu) by dgm (subscriber, #49227) [Link]

Also, any improvement to Atom performance can only be welcome.

Glibc change exposing bugs

Posted Nov 11, 2010 12:00 UTC (Thu) by alankila (subscriber, #47141) [Link]

I took a simple oprofile trace of me using my desktop for a while. Sad to say, but in that trace glibc's memcpy() used 0.24 % of time.

It would probably be better idea for majority of systems to just remove memcpy() and just replace it with memmove() which showed up with 0.17 %. Together, that would add up to 0.5 % at most, I suppose.

Glibc change exposing bugs

Posted Nov 11, 2010 16:26 UTC (Thu) by jedbrown (subscriber, #49919) [Link]

Here's my benchmark on Core 2. The Core 2 implementation in glibc-2.12.1 is *forward* (not reverse like on Nehalem, I don't know which way it is on Atom), and the performance difference between glibc and Linus' implementation goes both ways.

http://www.reddit.com/r/programming/comments/e4bq0/glibc_...