Announcement

Collapse
No announcement yet.

Glibc's Per-Thread Cache Is Helping Out Some Benchmarks

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

  • Glibc's Per-Thread Cache Is Helping Out Some Benchmarks

    Phoronix: Glibc's Per-Thread Cache Is Helping Out Some Benchmarks

    Released this week was the shiny new glibc 2.26 GNU C Library with the notable new feature being the per-thread cache for malloc...

    http://www.phoronix.com/scan.php?pag....26-Redis-Test

  • #2
    Nice. Specific solutions/optimizations are not expected to improve things across the board. As long as they don't introduce regressions, they're golden.

    Comment


    • #3
      It wouldn't hurt to include musl in these.

      Comment


      • #4
        musl is most likely going to be an absolute performance disaster. But that can be motivational.

        Comment


        • #5
          Originally posted by ayumu View Post
          It wouldn't hurt to include musl in these.
          just tested this... had to disable key security features in the compiler flags (FORTIFY_SOURCE and stack protector) but even with that, a musl-enabled redis runs at roughly half the performance of the glibc-2.26 redis (range is from 1.8 to 2.2 or so)

          Comment


          • #6
            Originally posted by bug77 View Post
            Nice. Specific solutions/optimizations are not expected to improve things across the board. As long as they don't introduce regressions, they're golden.
            Sometimes it does. The benefit here is the ability to alloc without a lock. The disadvantage is increased memory consumption in heavily threaded applications, such as Java, especially on 32-bit systems where address space is constrained.

            Comment


            • #7
              Originally posted by Mark Rose View Post

              Sometimes it does. The benefit here is the ability to alloc without a lock. The disadvantage is increased memory consumption in heavily threaded applications, such as Java, especially on 32-bit systems where address space is constrained.
              at least the heavily threaded applications is also directly where the benefits pay off (so it's not that you pay a price without benefits, they're at least correlated)

              do 32 bit systems still exist (where java and the like matter) ? Even android went 64 bit

              Comment


              • #8
                Originally posted by Mark Rose View Post

                Sometimes it does. The benefit here is the ability to alloc without a lock. The disadvantage is increased memory consumption in heavily threaded applications, such as Java, especially on 32-bit systems where address space is constrained.
                Didn't say it doesn't happen, just that it's not a sensible default expectation from these kind of things.

                Comment


                • #9
                  Originally posted by Mark Rose View Post

                  Sometimes it does. The benefit here is the ability to alloc without a lock. The disadvantage is increased memory consumption in heavily threaded applications, such as Java, especially on 32-bit systems where address space is constrained.
                  You must be joking :O Heavily threaded applications and 32-bit. Wut. In 2017. Yes, it's 2017.

                  Comment


                  • #10
                    Maybe someone with more practical wisdom could explain what these tests do and how do they relate to real world web applications.

                    Comment

                    Working...
                    X