Specifically its goals are low memory overhead and hardening. Safe defaults, and easy to swap to a performance-oriented malloc for those apps that want it.
My question is: why is Rust performance contingent on a C malloc?
Specifically its goals are low memory overhead and hardening. Safe defaults, and easy to swap to a performance-oriented malloc for those apps that want it.
My question is: why is Rust performance contingent on a C malloc?
> why is Rust performance contingent on a C malloc?
Because Rust switched to “system” allocators way back for compatibility with, well, the system, as well as introspection / perf tooling, to lower the size of basic programs, and to lower maintenance.
It used to use jemalloc, but that took a lot of space in even the most basic binary and because jemalloc is not available everywhere it still had to deal with system allocators anyway.
So basically, the Rust project made a bad decision and now it's all musl's fault? ;)
Sounds like a sane decision to me? Using musl is the developers decision, not Rusts.
It's not a developer decision on Alpine where musl is the system allocator. Otherwise I fully agree, application developers are mainly responsible for the performance of their applications.
Using the system allocator is also a developer decision. They can use any custom allocator they want. A lot of programs use Jemalloc regardless of what the system allocator is.
The rust project made a sensible decision given its direction and goals, and musl’s allocator is garbage for any multithreaded program.
> and musl’s allocator is garbage for any multithreaded program.
...it only matters if the threads allocate/free with such a high frequency that they run into contention, the C stdlib allocator is a shared resource and user code really shouldn't assume that the allocators fixes their poor design decisions for multithreaded code.
Ah yes, the "you're holding it wrong" argument.
If other allocators are able to handle a situation perfectly well, even a general-purpose allocator like the one in glibc, that suggests that musl's is deficient.
glibc's allocator is about 10x more code than musl's. Why should it be controversial that different C stdlib implementations set different priorities?
A smaller code base also means a smaller attack surface and fewer potential bugs.
The question remains: why does the Rust ecosystem depend so much on a system component they ultimately have no control over?
Intel has announced a desktop CPU with 52 cores.
Edit: To be more precise, an engineering sample was spotted.
AMD's threadrippers had 64 cores in 2020. The workstation targeted threadripper pro reaches 96. These are desktop parts, the top end of their server offering has 192 cores.
“The allocator is perfectly fine as long as you don’t use it” is more a confirmation than a disagreement.
never blame rust. rust is the replacement for C.
It's only for Rust binaries that are built with the the -linux-musl* (instead -linux-gnu*) toolchains, which are not the default, and usually used to make portable/static binaries.
Unless you're on a distro like Alpine where musl is the system libc. Which is common in, e.g., containers.
It's still possible to build Rust binaries with jemalloc if you need the performance (or another allocator). Also, it will heavily depend on the usecase; for many usecases, Rust will in fact pressure the heap less, precisely because it tracks ownership, and passing or returning structs by value (on the stack) is often "free" if you pass the ownership as well.