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

[coder]

What I'd like to know is about the down-sides. If I allocate something in one thread and deallocate it in another, is it going into the malloc cache of the second thread? This could be an issue if the threads in question have affinities for cores in different NUMA groups.

[smitty3268]

I imagine Firefox might benefit. AFAIK it still have disabled GPU acceleration by default, and so is pretty CPU-heavy.

Firefox long ago added their own internal memory allocator (forked from jemalloc) so this won't get hit at all. Mesa might actually be 1 app that improves - the compiler has shown speedups in the past based on memory allocation optimizations.

[Hi-Angel]

Firefox long ago added their own internal memory allocator (forked from jemalloc) so this won't get hit at all. Mesa might actually be 1 app that improves - the compiler has shown speedups in the past based on memory allocation optimizations.

By default Firefox is using jemalloc only on Windows. I.e. if you open about:buildconfig page on Windows, it reports --enable-jemalloc somewhere in the options. The default GNU/Linux builds of Firefox have no the option, so GNU/Linux probably uses a usual malloc.

[Hi-Angel]

What I'd like to know is about the down-sides. If I allocate something in one thread and deallocate it in another, is it going into the malloc cache of the second thread? This could be an issue if the threads in question have affinities for cores in different NUMA groups.

Probably worth questioning either on ML, or at least on #glibc Freenode channel.

[Uqbar]

Usual opensource fragmentation.
There used to be tcmalloc by Google and jemalloc later on, with the latter being actively developed.

Why not incorporating a mature and proven solution in libc instead of creating a third one?

Fragmentation!

[Guest]

Glibc was always quite slow. It's still faster than Windows NT when comes to thread creation, but ways slower than Linux kernel which is the fastest kernel in the world in this case.

This change should have significant impact on scalability. Sysbench could be interesting.

[Hi-Angel]

Usual opensource fragmentation.
There used to be tcmalloc by Google and jemalloc later on, with the latter being actively developed.

Why not incorporating a mature and proven solution in libc instead of creating a third one?

Fragmentation!

They're the memory allocators suited for specific workloads, that may impair performance in others. When I heard of jemalloc, and went googling, I seem to remember have seen a discussion on the matter on glibc ML. Though from a quick search this one is good too https://lwn.net/Articles/273084/

[Guest]

Usual opensource fragmentation.
There used to be tcmalloc by Google and jemalloc later on, with the latter being actively developed.

Why not incorporating a mature and proven solution in libc instead of creating a third one?

Fragmentation!

Usual stupidity. If you take a look those allocators are different and none of them is best for every purpose. There are at least three mallocs in Arma III to choose from. Proprietary fragmentation?

[Hi-Angel]

Usual stupidity. If you take a look those allocators are different and none of them is best for every purpose. There are at least three mallocs in Arma III to choose from. Proprietary fragmentation?

If ideal memory allocator was possible, probably it'd have been created already. I don't know constraints of memory allocation, but I think it's one of those tasks where the globally optimal solution is infeasible (e.g. may be because of high computational complexity), so you have to resort to heuristics and tricks to get something close.

[higuita]

Usual opensource fragmentation.
There used to be tcmalloc by Google and jemalloc later on, with the latter being actively developed.

Why not incorporating a mature and proven solution in libc instead of creating a third one?

Fragmentation!

Because not all apps really improve with the new mallocs ... some tasks like one malloc, other like others. Remember that you have many kind of apps running in linux, from render farms, or memory hungry to single thread or cpu hungry. There is no "one size fit all"
Also, unless you really understand how everything works, it is usually better to use the default... many apps tried to switch mallocs to solve some problem and then found other kind of problems. Mozilla took years to switch and fine-tune their malloc

botton line, glibc malloc is not perfect, but works well in most cases