Announcement

Collapse
No announcement yet.

Glibc Enables A Per-Thread Cache For Malloc - Big Performance Win

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

  • Glibc Enables A Per-Thread Cache For Malloc - Big Performance Win

    Phoronix: Glibc Enables A Per-Thread Cache For Malloc - Big Performance Win

    Glibc has added a per-thread cache to malloc and enabled it by default...

    http://www.phoronix.com/scan.php?pag...c-thread-cache

  • #2
    I think this email has some more detailed information: https://sourceware.org/ml/libc-alpha.../msg00452.html

    Comment


    • #3
      Just a note: golang has a lockless per-thread allocation cache since its introduction in 2009.

      Comment


      • #4
        About effing time!

        TCMalloc (thread caching malloc) has been doing that for more than a decade

        http://goog-perftools.sourceforge.net/doc/tcmalloc.html

        Comment


        • #5
          not much info about this news. how many nanoseconds did it save?

          Comment


          • #6
            Originally posted by cj.wijtmans View Post
            not much info about this news. how many nanoseconds did it save?
            See the email linked in first post, it's around 20% decrease in malloc times.

            I know too little about this subject to translate that into nanoseconds saved.

            Comment


            • #7
              I am pretty sure glibc has tried similar things in the past. It isn't as if it had no support for threads. It just wasn't very good.

              Comment


              • #8
                Originally posted by atomsymbol View Post
                Just a note: golang has a lockless per-thread allocation cache since its introduction in 2009.
                to have malloc cache you have to provide malloc. otherwise your cache will not affect code calling malloc directly like glibc itself

                Comment


                • #9
                  Genuine question :
                  - Which developer in his right mind would be calling malloc in a performance-critical part of the code ?

                  Are there that many *non-synthetic benchmarks* use cases where faster malloc really impacts performance of the software ?

                  Comment


                  • #10
                    Originally posted by DrYak View Post
                    Are there that many *non-synthetic benchmarks* use cases where faster malloc really impacts performance of the software ?
                    I imagine Firefox might benefit. AFAIK it still have disabled GPU acceleration by default, and so is pretty CPU-heavy.

                    Comment

                    Working...
                    X