On Wed, 22 Jul 2015 17:30:19 +0200, Sönke Ludwig wrote:
single multi-threaded one because of the garbage collector. The GC is
currently very inefficient in a multi-threaded scenario, so it's very
important to minimize it's use for high-performance multi-threaded
applications (use -version=VibeManualMemoryManagement for vibe.d in that
The GC will lock (for all threads) during allocation and during collection, this happens also for manual memory management as well (but the collection is spared). Even the single-threaded scenario will also flush cpu L1 cache at every allocation because of this synchronization, costing probably >100 cycles + contention :/
The only real solution is to use an experimental TLS GC that I added to a custom druntime/phobos here:
https://github.com/etcimon/druntime/tree/2.068-custom
https://github.com/etcimon/phobos/tree/2.068-custom
I wonder what the benchmark numbers would be in comparison! I use it because I don't construct an object in a thread and let it get collected in another, so I never got any problems with it with my vibe.d fork.