Poor memory allocation performance with a lot of threads on 36 core machine

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 18 February 2016 at 13:00:12 UTC, Witek wrote:
> So, the question is, why is D / DMD allocator so slow under 
> heavy multithreading? The working set is pretty small (few 
> megabytes at most), so I do not think this is an issue with GC 
> scanning itself.  Can I plug-in tcmalloc / jemalloc, to be used 
> as the underlying allocator, instead of using glibc? Or is D 
> runtime using mmap/srbk/etc directly?
>
> Thanks.

Currently, all memory allocations use a global GC lock[1]. As 
such, presently high-parallelism programs need to avoid 
allocating memory via the GC.

You can avoid this problem by using a different allocation / 
memory management strategy. You may want to have a look at 
std.experimental.allocator.

[1]: 
https://github.com/D-Programming-Language/druntime/blob/30f8c1af39eb17d8ebec1f5fd401eb5cfd6b36da/src/gc/gc.d#L348-L370