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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

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

    Comment


    • #3
      About effing time!

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

      Comment


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

        Comment


        • #5
          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


          • #6
            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


            • #7
              Originally posted by atomsymbol
              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


              • #8
                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


                • #9
                  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


                  • #10
                    Originally posted by DrYak View Post
                    Genuine question :
                    - Which developer in his right mind would be calling malloc in a performance-critical part of the code ?
                    Well, pretty much anything not dealing only with small strings and fixed-sized arrays. So, that's basically most real-world software.

                    Most interesting data structures require dynamic allocation.

                    Comment

                    Working...
                    X