GNU C Library 2.26 Released With Per-Thread Cache For Greater Performance

[phoronix]

Phoronix: GNU C Library 2.26 Released With Per-Thread Cache For Greater Performance

Today marks the release of GNU C Library version 2.26 and it's a big release with one feature we have been looking forward to...

http://www.phoronix.com/scan.php?page=news_item&px=GNU-C-Library-2.26

[rene]

yup, updated - https://t2sde.org/packages/glibc.html, let's rebuild world and see what fails ;-)

[Krejzi]

yup, updated - https://t2sde.org/packages/glibc.html, let's rebuild world and see what fails ;-)

On my LFS build, it was gcc 7.1.0 that failed (fixed in newer GCC snapshot), clang (compiler-rt part) of llvm-4.0.1, chromium (bug report filled) and at least one more package.

Edit: There was also qemu and flex (not compile, but runtime error)

[Azpegath]

Will we get performance tests?

[linuxgeex]

Will we get performance tests?

People use XMalloc or stack allocation for thread-local storage, both of which don't need locks. The great thing about this is that it will reduce the need for XMalloc and stack allocation, which will simplify coding and help prevent sloppy programmers from writing code vulnerable to buffer overflows. So it's good for the language, programmers, and end users... I doubt there will be any meaningful performance improvements in any major packages as a result of this.

[arjan_intel]

BTW I did run some tests on malloc performance between glibc 2.25, glibc 2.26 and jemalloc:

https://openbenchmarking.org/result/1708052-TY-REDISMALL91

shows a very nice performance increase for glibc 2.26

[linuxgeex]

People use XMalloc or stack allocation for thread-local storage, both of which don't need locks. The great thing about this is that it will reduce the need for XMalloc and stack allocation, which will simplify coding and help prevent sloppy programmers from writing code vulnerable to buffer overflows. So it's good for the language, programmers, and end users... I doubt there will be any meaningful performance improvements in any major packages as a result of this.

Holy crap though when a major app like Redis fails to optimise malloc it makes a huge difference. +80% throughput for LPOP!

[rene]

Holy crap though when a major app like Redis fails to optimise malloc it makes a huge difference. +80% throughput for LPOP!

I do not think it is the job of the app to optimize malloc, that should actually indeed be the job of the low level experts in the libc and kernel, ...

[linuxgeex]

I do not think it is the job of the app to optimize malloc, that should actually indeed be the job of the low level experts in the libc and kernel, ...

Exactly what I said above...