| |||||||||||||
Glibc change exposing bugsGlibc change exposing bugsPosted Nov 10, 2010 19:41 UTC (Wed) by mrshiny (subscriber, #4266)Parent article: Glibc change exposing bugs
I had to do something like this years ago when glibc changed and quake2 stopped working. Again, it was sound-related, and again, it was memcpy optimizations that broke things. I made a simple preload for memcpy that did the dumbest possible memcpy I could think of, which worked well enough for quake2. I'm a little disappointed that history is repeating itself again.
(Log in to post comments)
Glibc change exposing bugs Posted Nov 10, 2010 19:49 UTC (Wed) by jwb (guest, #15467) [Link]
I'm glad to see glibc willing to commit changes like these. A modern CPU is absurdly fast and I want my software to run as quickly as possible. I specifically DO NOT WANT progress on glibc performance to be sacrificed to the implementation flaws of proprietary crapware ported from other platforms.
Glibc change exposing bugs Posted Nov 10, 2010 20:01 UTC (Wed) by mrshiny (subscriber, #4266) [Link]
Please.
First of all, glibc supports proprietary software, which is why they allow proprietary software to link to it. So punishing certain programs for license choice by making subtle (and sometimes unjustifiable) changes to API seems like a highly passive-aggressive approach to their ideology.
Second of all, there MUST be a way to preserve backwards compatibility AND allow for future progress. Remember: all of your open-source programs which exhibit this bug are just as broken as Flash, except that if someone tracks it down in the Free software it can be fixed for future versions. But that doesn't help anyone who already has the software installed. I just can't imagine that the glibc people couldn't come up with ANY approach that works for everyone. Off the top of my head I can think of several; probably there are reasons why they are problematic, but in that bugzilla entry even Linus Torvalds was unable to prove that the glibc approach was warranted at all, let alone warranted for everyone all the time.
Glibc change exposing bugs Posted Nov 10, 2010 22:49 UTC (Wed) by cesarb (subscriber, #6266) [Link]
> So punishing certain programs for license choice by making subtle (and sometimes unjustifiable) changes to API seems like a highly passive-aggressive approach to their ideology.
This was not an API change. The memcpy() API has always been that the regions cannot overlap, and has been so for decades. This was just a change in the implementation details.
Glibc change exposing bugs Posted Nov 11, 2010 0:33 UTC (Thu) by marcH (subscriber, #57642) [Link]
> This was not an API change.
Agreed, let's not confuse API change with "change of undefined behaviour". It may look the same but it is different.
That's what symbol versioning is all about. Posted Nov 10, 2010 23:03 UTC (Wed) by khim (subscriber, #9252) [Link] GLibC does have such mechanism: it's called ELF symbol versioning. But the policy does not cover cases similar to discussed one: if it's bug in a program (and the fact that regions must not intersect is well-documented one... heck, it's reason for memmove(3) existence), then there will be no new version of function. The question of "do we actually want such change" is separate issue.
Glibc change exposing bugs Posted Nov 10, 2010 20:05 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
did you read the comments and see that Linus published benchmarks that showed that this change was not faster if the data was cached, and in the noise if the data is not cached (and even then the non glib version won 6 of 10 tests, but the results were very noisy)
Glibc change exposing bugs Posted Nov 10, 2010 20:08 UTC (Wed) by jwb (guest, #15467) [Link]
Sure, but Linus doesn't even say what CPU he tested on. The commit message for the change to memcpy claims a 4x improvement on Core 2.
Glibc change exposing bugs Posted Nov 10, 2010 21:03 UTC (Wed) by fuhchee (subscriber, #40059) [Link]
It would be nice if such patches were accompanied not but just statements of seen performance changes, but actual reproduction scripts, so one can test for oneself.
Glibc change exposing bugs Posted Nov 10, 2010 23:05 UTC (Wed) by patrick_g (subscriber, #44470) [Link] >>> Linus doesn't even say what CPU he tested onLinus use a Core i5 at home (see this post).
Glibc change exposing bugs Posted Nov 11, 2010 0:26 UTC (Thu) by jwb (guest, #15467) [Link]
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.
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_...
Glibc change exposing bugs Posted Nov 11, 2010 0:57 UTC (Thu) by MattPerry (guest, #46341) [Link]
> Linus use a Core i5 at home (see this post).
But we don't know if he ran his test on that computer. There's not enough information to tie the two together. It would help if Linus stated what CPU he used to run the test on.
|
|||||||||||||