nice
Conversation
Replying to
I am guessing what the article talks about, but the glibc malloc underperforms for most things other than shell interpreters and so does macos allocator. Platform allocators tend to bias different things than the horrified who later look at them with roflscale eyes
1
The claim in the article is that on Linux you can malloc anytime and it'll always be fast. I'm not at all surprised by the article content, but it's much more true to it's emotion than it is true to how the world works. LLVM gets a lot faster for most workloads w/ {je,pt}malloc
1
They're using the legacy C runtime shipped with the OS. It exists for backwards compatibility and they can't significantly change the malloc implementation due to backwards compatibility with all kinds of latent memory corruption bugs and assumptions about the malloc heap layout.
1
If they were using the modern C runtime, performance would be much better. It should also be noted that Windows does more hardening than glibc and therefore pays a higher performance cost for that by default. Performance is not the only concern for a general purpose allocator.
1
glibc malloc is essentially entirely focused on microbenchmark performance. It has massive issues with fragmentation, long term performance and real world scalability. It's also the furthest thing from hardened. It has a few minor sanity checks they mostly bypassed with caches.
Despite glibc malloc being almost entirely focused on microbenchmark performance rather than real world applications, it still performs significantly worse in those contrived cases not representing real world applications than many modern allocator implementations.
1
glibc isn't much worse than jemalloc on most microbenchmarks but in real world applications it's almost always massively worse, especially long-lived applications where glibc massively fragments memory on multiple levels. glibc malloc's scaling hack also doesn't really work.
1
1
Show replies