Announcement

Collapse
No announcement yet.

Mesa Looks At Switching To Jemalloc For Faster Performance

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

  • #31
    Originally posted by sdack View Post
    [CODE]Default glibc:
    real 2m56.383s
    user 20m13.058s
    sys 1m29.841s

    jemalloc 4.2.1:
    real 2m55.498s
    user 19m34.992s
    sys 1m53.795s
    btw, i can't see 10% improvements over glibc which was seen by marek. maybe your jemalloc is broken?

    Comment


    • #32
      You'll only see the 10% reduction in compile time (= 11.1% improvement in compiler performance) with the GLSL compiler in Mesa. jemalloc is unlikely to make that big difference elsewhere.

      Comment


      • #33
        So many allocators! How about using the binned allocator? It works for Unreal Engine 4

        Comment


        • #34
          Originally posted by GreatEmerald View Post
          So many allocators! How about using the binned allocator? It works for Unreal Engine 4
          why would you use a binned allocator?

          Comment


          • #35
            Originally posted by sdack View Post
            Did they test it with locklessmalloc, too? http://locklessinc.com/benchmarks_allocator.shtml
            It's good, but it's not clearly the best, and is terrible when it comes to memory usage.

            https://www.percona.com/blog/2012/07...l-performance/

            Google's tcmalloc, from various benchmarks I've seen, seems the best general purpose allocator.
            I'd be curious to see how well tlsf would work for Mesa, but there's not been a new release of that for awhile.

            Regardless, glibc's allocator is awful.

            Edit: lockfree is also not really lockfree, nor is it simple. See http://programmers.stackexchange.com...emory-allocato
            Last edited by liam; 30 September 2016, 12:38 AM.

            Comment


            • #36
              Originally posted by liam View Post
              It's good, but it's not clearly the best ...
              Nobody said it's clearly the best. If one wanted to make an assumption (perhaps to avoid questions) on what is best then the correct assumption would be that the best is jemalloc, because this is what they are going for.

              It's then not general purpose when they have a specific purpose in mind. An allocator may be general purpose, but this is not the use case here.

              It's called lockfree, because it doesn't lock threads in the classic sense, meaning, through library calls such as pthread_mutex_lock(), which you'll find in tcmalloc and jemalloc.

              And I am calling it simple, because it doesn't come with autoconf configuration and consists of a single C file with a few headers. tcmalloc uncompressed is 6,160KB, jemalloc is 2,460KB and llmalloc is 180KB.

              Comment


              • #37
                Originally posted by schmidtbag View Post
                Bloat, primarily. It may not be much (I don't know how much exactly) but stuff like this adds up over time.
                Seems to be 243KB for libjemalloc1.

                Comment


                • #38
                  Originally posted by marek View Post
                  You'll only see the 10% reduction in compile time (= 11.1% improvement in compiler performance) with the GLSL compiler in Mesa. jemalloc is unlikely to make that big difference elsewhere.
                  And what happens if you tune glibc with MALLOC_ARENA_MAX varible to match number of threads?

                  Just guessing, as that seems similar what jemalloc do.

                  Comment


                  • #39
                    Interestingly, quite the opposite to what the many says, it is unused by firefox, i.e.
                    Code:
                    % cat /proc/`pgrep firefox`/maps | grep malloc
                    % cat /proc/`pgrep firefox`/maps | grep libc
                    […]
                    7fcae5990000-7fcae5b25000 r-xp 00000000 08:07 2100391                    /usr/lib/libc-2.24.so
                    7fcae5b25000-7fcae5d24000 ---p 00195000 08:07 2100391                    /usr/lib/libc-2.24.so
                    7fcae5d24000-7fcae5d28000 r--p 00194000 08:07 2100391                    /usr/lib/libc-2.24.so
                    7fcae5d28000-7fcae5d2a000 rw-p 00198000 08:07 2100391                    /usr/lib/libc-2.24.so
                    % pacman -Qi jemalloc | grep "Required By"
                    Required By     : mariadb  mariadb-clients
                    Probably Firefox did use jemalloc at some point of time, but then for some reason they decided to quit.

                    Comment


                    • #40
                      Originally posted by Hi-Angel View Post
                      Interestingly, quite the opposite to what the many says, it is unused by firefox, i.e.
                      Code:
                      % cat /proc/`pgrep firefox`/maps | grep malloc
                      % cat /proc/`pgrep firefox`/maps | grep libc
                      […]
                      7fcae5990000-7fcae5b25000 r-xp 00000000 08:07 2100391 /usr/lib/libc-2.24.so
                      7fcae5b25000-7fcae5d24000 ---p 00195000 08:07 2100391 /usr/lib/libc-2.24.so
                      7fcae5d24000-7fcae5d28000 r--p 00194000 08:07 2100391 /usr/lib/libc-2.24.so
                      7fcae5d28000-7fcae5d2a000 rw-p 00198000 08:07 2100391 /usr/lib/libc-2.24.so
                      % pacman -Qi jemalloc | grep "Required By"
                      Required By : mariadb mariadb-clients
                      Probably Firefox did use jemalloc at some point of time, but then for some reason they decided to quit.
                      Well, whatever library's malloc is used, it's statically compiled in.
                      Code:
                      (gdb) info symbol malloc
                      malloc in section .text of /usr/lib/firefox/firefox
                      Interestingly though, I asked at #firefox (irc.mozilla), they say to have "--enable-jemalloc" option in the "about:buildconfig" on Windows. I didn't have it.

                      Comment

                      Working...
                      X