4 ms·

Glibc Enables a Per-Thread Cache for Malloc – Big Performance Win

12 points by jjuhl 9y ago

jjuhl 9y ago
More details: https://sourceware.org/ml/libc-alpha/2017-01/msg00452.html https://sourceware.org/ml/libc-alpha/2017-01/msg00452.html
mtanski 9y ago
All I can say is finally. Such a shame that the default malloc on most Linux systems was so far behind in terms of performance (jemalloc/tcmalloc) for more then a decade now. I wonder how long it'll take for this implementation to shake out the many bugs (fragmentation issues / worse case behavior) the early version of jemalloc/tcmalloc suffered from.
kazinator 9y ago
Well, big performance win for applications whose developers let malloc be the major bottleneck.
- wbl 9y ago
  Systems should make malloc fast so I don't have to write my own wrapper. Sure, in some cases I know a lot more, but why confuse the heck out of valgrind when I don't have to.
  - kazinator 9y ago
    No malloc optimization can eliminate the waste of re-initializing an object from scratch. The fastest caching will be caching of almost-ready-to-go objects that don't require allocation and initialization from scratch. No malloc can provide that while sticking with malloc semantics.
- syncsynchalt 9y ago
  The speed of per-thread arenas has been proven for at least a decade. Why snark about getting it in glibc? I'm a little shocked it wasn't already the default.
  - kazinator 9y ago
    It's a high risk area with no benefit to programs which don't spend a lot of time in malloc, or which recycle entire objects (dispensing with the cost of fully re-initializing recycled memory, not only the cost of malloc). It's also not true that glibc's malloc has no arenas (which someone may interpret that way); they are just not tied to threads. For something like twenty years, glibc's malloc has had thread support roughly as follows: a thread walks a list of arenas and tries to acquire one without blocking. Then it allocates from that arena. So it's not exactly like there is one big lock around malloc. But threads don't have affinity to go to the same arena.

12 points by jjuhl 9y ago

More details: https://sourceware.org/ml/libc-alpha/2017-01/msg00452.html https://sourceware.org/ml/libc-alpha/2017-01/msg00452.html

mtanski 9y ago

All I can say is finally. Such a shame that the default malloc on most Linux systems was so far behind in terms of performance (jemalloc/tcmalloc) for more then a decade now. I wonder how long it'll take for this implementation to shake out the many bugs (fragmentation issues / worse case behavior) the early version of jemalloc/tcmalloc suffered from.

kazinator 9y ago

Well, big performance win for applications whose developers let malloc be the major bottleneck.

wbl 9y ago
Systems should make malloc fast so I don't have to write my own wrapper. Sure, in some cases I know a lot more, but why confuse the heck out of valgrind when I don't have to.
- kazinator 9y ago
  No malloc optimization can eliminate the waste of re-initializing an object from scratch. The fastest caching will be caching of almost-ready-to-go objects that don't require allocation and initialization from scratch. No malloc can provide that while sticking with malloc semantics.
syncsynchalt 9y ago
The speed of per-thread arenas has been proven for at least a decade. Why snark about getting it in glibc? I'm a little shocked it wasn't already the default.
- kazinator 9y ago
  It's a high risk area with no benefit to programs which don't spend a lot of time in malloc, or which recycle entire objects (dispensing with the cost of fully re-initializing recycled memory, not only the cost of malloc). It's also not true that glibc's malloc has no arenas (which someone may interpret that way); they are just not tied to threads. For something like twenty years, glibc's malloc has had thread support roughly as follows: a thread walks a list of arenas and tries to acquire one without blocking. Then it allocates from that arena. So it's not exactly like there is one big lock around malloc. But threads don't have affinity to go to the same arena.