The rust project made a sensible decision given its direction and goals, and musl’s allocator is garbage for any multithreaded program.
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.