Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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?pag...C-Library-2.26

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

    Comment


    • #3
      Originally posted by rene View Post
      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)
      Last edited by Krejzi; 02 August 2017, 01:21 PM.

      Comment


      • #4
        Will we get performance tests?

        Comment


        • #5
          Originally posted by Azpegath View Post
          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.

          Comment


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

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

            shows a very nice performance increase for glibc 2.26

            Comment


            • #7
              Originally posted by linuxgeex View Post

              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!

              Comment


              • #8
                Originally posted by linuxgeex View Post

                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, ...

                Comment


                • #9
                  Originally posted by rene View Post

                  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...

                  Comment

                  Working...
                  X