Glibc change exposing bugs

Posted Nov 11, 2010 0:32 UTC (Thu) by kunitz (subscriber, #3965)
Parent article: Glibc change exposing bugs

Linus did a performance test of his simple memcpy() against the new glibc version. He couldn't find strong evidence that the new glibc version is actually faster. I would question optimizations that have no measurable benefits but the downside to break running code relying on undefined behaviour.

Glibc change exposing bugs

Posted Nov 11, 2010 0:44 UTC (Thu) by bojan (subscriber, #14302) [Link] (4 responses)

According to some comments above, he was testing on the CPU that didn't benefit form the optimisations (Core i5 instead of Core 2/Atom), so he couldn't have seen any improvements anyway.

Glibc change exposing bugs

Posted Nov 11, 2010 7:20 UTC (Thu) by kunitz (subscriber, #3965) [Link] (3 responses)

If that's the case the optimization shouldn't be enabled on Core i5. I guess it's more difficult to test for the CPU then for SSE 4.x presence.

Glibc change exposing bugs

Posted Nov 11, 2010 18:23 UTC (Thu) by oak (guest, #2786) [Link]

> If that's the case the optimization shouldn't be enabled on Core i5

What would be the point of slowing down memcpy for all CPUs (by adding an extra check for cached CPU type variable value)? As long as the change doesn't slow down things for other CPUs, and considerably speeds it up on some, it sounds fine...

Glibc change exposing bugs

Posted Nov 12, 2010 0:37 UTC (Fri) by jamesh (guest, #1159) [Link] (1 responses)

That would mean that a developer using a Core i5 will not be able to reproduce some bugs seen by users on Core 2 and Atom chips. Is that actually desirable?

Glibc change exposing bugs

Posted Nov 12, 2010 10:51 UTC (Fri) by marcH (subscriber, #57642) [Link]

No, but something like this happens every time developers rely on undefined behaviour, so we just have to live with it.