4 ms·
(Author) The refcounting version is about as slow as the garbage collected D version on the benchmark. Refcounting operations can often be elided if you optimiz
by FeepingCreature 3y ago
(Author) The refcounting version is about as slow as the garbage collected D version on the benchmark. Refcounting operations can often be elided if you optimize a bit.
And this is not a "supreme importance of performance" microoptimization. This single change moved me from place 23 to place 5. That's a 2x speedup!
- rwmj 3y agoYou won't see the problem with refcounting in microbenchmarks. It manifests when you have multiple threads accessing single pieces of data, or are under memory pressure. Refcounting turns reads into writes, unless steps are taken to avoid that, and/or you store the refcounts separately from the data.
- FeepingCreature 3y agoMultiple threads accessing single pieces of data is always slow. The standard answer is "don't do that"; you can do that just as well with GC or manual management.
- rwmj 3y agoConfirming you have no idea what you're talking about.
- kragen 3y agoas i understand it, multiple threads reading single pieces of data is faster than multiple threads reading different copies of the same data, as long as you don't have to lock them or increment their reference counts. it's faster because it reduces cache pressure. rcu is a widely used, highly performant way for many threads to read single pieces of data without having to lock them even if they might change. often you can even implement garbage collection without having to acquire readlocks on garbage-collectable things
- jeffbee 3y agoIt only changes your rank in this benchmark because the benchmark fails to use whole program optimization, ie as a benchmark it is meaningless.
- FeepingCreature 3y agoWhopr doesn't fix the issue, because runtime calls (happen a lot with arrays) shouldn't be inlined; all that achieves is blowing out your instruction cache.