3 ms·

So which Malloc should we be using? How about setting that as a default? If apparently the trade off is so cookie cutter clear.

by spockz 3y ago

jeffbee 3y ago
If you have a non-trivial workload (i.e. one that costs money) you should shop around and use the one that is the most efficient in your application.
kelnos 3y ago
I assume what the GP actually meant was that glibc's allocator isn't tuned for any specific workloads. It tries to be a jack-of-all-trades, and in doing so, just ends up being okay-ish. As for what allocator you should be using, it depends on your workload. You'd need to test out some different options to see what works best. And "best" might also be something you have to define. Maybe you're ok with higher baseline memory usage if allocations are faster. Or maybe you want the lower memory usage.
- vlovich123 3y ago
  Actually, mimalloc and tcmalloc both show that across almost any workload they outperform glibc. It’s difficult to outperform everywhere of course, but in terms of “works best without knowing the workload a priori”, tcmalloc and mimalloc should handily trounce glibc. Know if you know your workload and start tuning glibc, maybe it can outperform? Not sure but I’d also be skeptical. Tcmalloc and mimalloc both apply really advanced techniques that also require newer kernel support to implement user side RCU iirc. Glibc’s allocator by comparison is much longer in the tooth and just can’t compete on that. Most workloads don’t care of course, but glibc’s penchant for hanging onto RAM when not needed is one very user visible consequence of this.
vlovich123 3y ago
Tcmalloc (not the gperftools variant but the new one) and mimalloc would be the 2 I would try first. I am honestly surprised no one has bothered replacing the system default for distros as a better default allocator would free up RAM since both tcmalloc and mimalloc do a good job of knowing when to release memory back to the OS (not to mention that they’re generally faster allocators anyway).
- jeffbee 3y ago
  Well, tcmalloc can’t be dynamically loaded, so it can’t be your system allocator. But mimalloc would be worth testing in that role.
  - vlovich123 3y ago
    Why is that the requirement? Eg if glibc decided to replace its own allocator with tcmalloc, what would be the blocker?

So which Malloc should we be using? How about setting that as a default? If apparently the trade off is so cookie cutter clear.

by spockz 3y ago

So which Malloc should we be using? How about setting that as a default? If apparently the trade off is so cookie cutter clear.

jeffbee 3y ago

If you have a non-trivial workload (i.e. one that costs money) you should shop around and use the one that is the most efficient in your application.

kelnos 3y ago

I assume what the GP actually meant was that glibc's allocator isn't tuned for any specific workloads. It tries to be a jack-of-all-trades, and in doing so, just ends up being okay-ish. As for what allocator you should be using, it depends on your workload. You'd need to test out some different options to see what works best. And "best" might also be something you have to define. Maybe you're ok with higher baseline memory usage if allocations are faster. Or maybe you want the lower memory usage.

vlovich123 3y ago
Actually, mimalloc and tcmalloc both show that across almost any workload they outperform glibc. It’s difficult to outperform everywhere of course, but in terms of “works best without knowing the workload a priori”, tcmalloc and mimalloc should handily trounce glibc. Know if you know your workload and start tuning glibc, maybe it can outperform? Not sure but I’d also be skeptical. Tcmalloc and mimalloc both apply really advanced techniques that also require newer kernel support to implement user side RCU iirc. Glibc’s allocator by comparison is much longer in the tooth and just can’t compete on that. Most workloads don’t care of course, but glibc’s penchant for hanging onto RAM when not needed is one very user visible consequence of this.

vlovich123 3y ago

Tcmalloc (not the gperftools variant but the new one) and mimalloc would be the 2 I would try first. I am honestly surprised no one has bothered replacing the system default for distros as a better default allocator would free up RAM since both tcmalloc and mimalloc do a good job of knowing when to release memory back to the OS (not to mention that they’re generally faster allocators anyway).

jeffbee 3y ago
Well, tcmalloc can’t be dynamically loaded, so it can’t be your system allocator. But mimalloc would be worth testing in that role.
- vlovich123 3y ago
  Why is that the requirement? Eg if glibc decided to replace its own allocator with tcmalloc, what would be the blocker?