I use the latest LTS release of Ubuntu, which is Ubuntu 22.04, and the library versions are what Ubuntu provides. So these are the libraries that most of us use when using Ubuntu LTS. Regardless, I am happy that tcmalloc and jemalloc continue to improve.
Occasionally I get "your version of X is too old" when I publish results for X, and I have had mixed results in the past when doing even more work to test the newer thing. In this case I am not going to put in that extra time. But in a few years I might revisit the topic and get newer versions of X, of course, there will be feedback that the version of X I test in 2028 is from 2026 and the story repeats.
But the thing that doesn't get much discussion in public is the drama that happens from upgrades when behavior changes WRT file systems, kernels, device drivers, CPU frequency governors, etc.
It took a few weeks to figure that out for several of my servers. So I am slow to upgrade things once that gets stable -- and it has been stable for my servers for about 6 months.
Note also that, on Linux, RSS is not guaranteed to be accurate: "For making accounting scalable, RSS related information are handled in an asynchronous manner and the value may not be very precise." [1]
Seems like there's no attention paid to documenting (or just discovering -- looks like the heaps in question were just the ones provided by their linux distro) the build and runtime configuration in use. There are a lot of hardening/tracing/robustness/shenaniganproofing features in modern heaps, and if you're going to make noise about a few percent of performance it's really important to be clear about exactly what the software you're measuring is doing.
To be blunt: my gut would say that glibc on typical distros is more hardened than default builds of alternative heap implementations, and if it's only off by a few percent it might well be the faster code if measured apples-to-apples.
Author here. The interesting point was that RSS is much too large with glibc malloc + RocksDB/MyRocks. The performance differences aren't a big deal, but OOM because RSS is 2X or 3X larger than it should be is a big deal. Of course, that problem is workload specific, but RocksDB/MyRocks are a workload on which I focus.
I lurk on email lists for RocksDB and OOM from glibc malloc is a problem for users -- the solution is easy, use jemalloc or tcmalloc.
Yes there is lots of evidence that jemalloc fares better in high concurrency applications.
Fun fact, jemalloc was the default allocator for rust but was dropped off and use default system allocator to have smaller binary size
The post was written two days ago, but the allocator versions are between three and six years old.
Nowadays, there are at least two different versions of tcmalloc: the one from https://github.com/google/tcmalloc/ is newer (it has rseq support, for example), and the version bundled in https://github.com/gperftools/gperftools.
Blog author here.
I use the latest LTS release of Ubuntu, which is Ubuntu 22.04, and the library versions are what Ubuntu provides. So these are the libraries that most of us use when using Ubuntu LTS. Regardless, I am happy that tcmalloc and jemalloc continue to improve.
Occasionally I get "your version of X is too old" when I publish results for X, and I have had mixed results in the past when doing even more work to test the newer thing. In this case I am not going to put in that extra time. But in a few years I might revisit the topic and get newer versions of X, of course, there will be feedback that the version of X I test in 2028 is from 2026 and the story repeats.
Ubuntu LTS releases come out every two years, so the latest one is 24.04.
Yeah, I missed that. I have ~10 servers in my test pool, all are still on 22.04. Perhaps I upgrade them later this year.
But the thing that doesn't get much discussion in public is the drama that happens from upgrades when behavior changes WRT file systems, kernels, device drivers, CPU frequency governors, etc.
It took a few weeks to figure that out for several of my servers. So I am slow to upgrade things once that gets stable -- and it has been stable for my servers for about 6 months.
RSS = Resident Set Size. https://en.wikipedia.org/wiki/Resident_set_size
Note also that, on Linux, RSS is not guaranteed to be accurate: "For making accounting scalable, RSS related information are handled in an asynchronous manner and the value may not be very precise." [1]
[1] https://www.kernel.org/doc/html/latest/filesystems/proc.html
http://ithare.com/testing-memory-allocators-ptmalloc2-tcmall...
Seems like there's no attention paid to documenting (or just discovering -- looks like the heaps in question were just the ones provided by their linux distro) the build and runtime configuration in use. There are a lot of hardening/tracing/robustness/shenaniganproofing features in modern heaps, and if you're going to make noise about a few percent of performance it's really important to be clear about exactly what the software you're measuring is doing.
To be blunt: my gut would say that glibc on typical distros is more hardened than default builds of alternative heap implementations, and if it's only off by a few percent it might well be the faster code if measured apples-to-apples.
Author here. The interesting point was that RSS is much too large with glibc malloc + RocksDB/MyRocks. The performance differences aren't a big deal, but OOM because RSS is 2X or 3X larger than it should be is a big deal. Of course, that problem is workload specific, but RocksDB/MyRocks are a workload on which I focus.
I lurk on email lists for RocksDB and OOM from glibc malloc is a problem for users -- the solution is easy, use jemalloc or tcmalloc.
[dead]