

Merging lock elision into glibc - signa11
http://lwn.net/SubscriberLink/557222/f7db853fdfb3bc11/

======
_stephan
Has anyone seen performance measurements for hardware lock elision? What's the
performance gain/loss in the uncontended case? How costly is an aborted
transaction?

~~~
traskjd
The folks at Sisoft have written up about the changes and included some
examples of the performance difference it can make:

[http://www.sisoftware.co.uk/?d=qa&f=ben_mem_hle](http://www.sisoftware.co.uk/?d=qa&f=ben_mem_hle)

------
ape4
Now glibc is more open to changes it would be cool if they could add some more
interesting features.

~~~
ethomson
Such as?

~~~
ape4
Well I am probably going to be shot down here. glibc has all the basics down.
And its on every Linux (and other OSes) box. How about letting fopen() open a
URL? It would be great if any *nix code could do that. There already a a bunch
of sorts qsort(), heapsort(), etc. But there isn't a sort for huge array using
disk or mapped memory (that I know of). How about making qsort() work
differently based on an environment variable? OK fire away.

~~~
ethomson
Well, the big problem here is that glibc _isn 't_ on every other OSes box.
FreeBSD uses its own libc, as does Solaris, HP-UX, AIX, etc. In fact, the
latter three are probably more in common with each other than with glibc. And
certainly the CRT on Windows is a different beast entirely.

Personally, I want a predictable API between different libc versions; I don't
want to deal with somebody's code that assumed that they could fopen(3) a URL
and have it do something useful. That Solaris and Linux (say) set errno
slightly differently for the same error is enough for me to pull my hair out.

And yes, I realize I brought Windows into this argument, but at least _you
know_ that Windows is always going to be a little bit different, whereas you
expect all the Unix libc implementations to act mostly the same way for most
of the things, even though in your cold, cynical heart you realize that's
idealistic.

But my cold, cynical heart _is_ still idealistic and believes that all
fopen(3) should be fopen(3) everywhere. So if you can get all of the vendors
on board, then let's talk.

Otherwise, let's just use libcurl.

