Intel Developer's New Proposal For Shipping Optimized Glibc Subset (libcpu-rt-c)

[phoronix]

Phoronix: Intel Developer's New Proposal For Shipping Optimized Glibc Subset (libcpu-rt-c)

While the Intel Open-Source Technology Center invests heavily into the GNU/Linux toolchain in ensuring their future processors will have their full feature set and performance potential exploited, when it comes to the GNU C Library "glibc" in particular it can be quite a while before Linux distributions pull in a new release that contains various Intel performance optimizations. As a result, Intel Linux veteran toolchain developer H.J. Lu has laid out a new proposal...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-libcpu-rt-c-Proposal

[miskol]

Maybe something like runtime autodetection for CPU features will be be much better. But it is really hard as all this AVX/SSE/NEON expect memory alignment

[jabl]

Maybe something like runtime autodetection for CPU features will be be much better. But it is really hard as all this AVX/SSE/NEON expect memory alignment

glibc already does that. The problem is that a 5 year old glibc release won't contain the optimizations for cpu's released today.

Then again, if the distributors won't backport new optimized functions into their old glibc's today, why would they update this new libcpu-rt-c library?

[M@yeulC]

I would even go the extra mile by having glibc try to load the optimized functions (replacing function pointers in a call table), instead of having to rely on LD_PPRELOAD. Of course, that change would need to trickle in with new glibc releases, but that would make a nice addition to the LD_PRELOAD method.

[flower]

Then again, if the distributors won't backport new optimized functions into their old glibc's today, why would they update this new libcpu-rt-c library?

i guess it is easier to test as it is only a glibc internal change.

[geearf]

I thought it was some Clear Linux optimizations pushed onto others :/

[ms178]

Every bit of performance improvements are very welcome, and hopefully somewhen in the future we all use software which automatically could detect and use all of the ressources of a particular device efficiently for the task at hand, e.g. CPU, GPU, FPGAs, DSPs etc. seemlessly working together.

[toojays]

glibc already does that. The problem is that a 5 year old glibc release won't contain the optimizations for cpu's released today.

Then again, if the distributors won't backport new optimized functions into their old glibc's today, why would they update this new libcpu-rt-c library?

I am one of the people who has asked Intel for this.

At my work we make an appliance based on CentOS. We aren't comfortable with switching out glibc for one we build ourself - it's a critical system component and we want to be able to get security patches from CentOS/Red Hat. But being able to drop-in a newer version of just the memory copy and strings library? Yes please!

I have implemented one of these myself to get an AVX2 memcpy on CentOS 6 running on a Sandy Bridge CPU. It took considerable effort to figure out how to disentangle the glibc memcpy from the rest of glibc. Having something like this available upstream would be most welcome.