Why is D's GC slower than GO's?

[Walter Bright]

On 10/28/2022 7:09 AM, ryuukk_ wrote:
> i dab with zig a little, even thought i hate 
> its ergonomics, it has the features that matter to me as builtin language feature

zig doesn't have a gc. D's gc is optional.

> i want D to grow, and it starts by acknowledging your shortcomings

 > a GC that is slower than GO's GC

And I acknowledge that. It will never be as fast as GO's GC. The reason is a 
technical one. GO is a GC-only language, which means it is optimized for the GC. 
All GO allocations are allocated on the GC heap, although it does do escape 
analysis to figure out what can be allocated on the stack instead. (Java does 
this as well.)

With such heavy GC allocation, a reasonable tradeoff is to insert "write gates" 
on every write through a pointer. This informs the GC that the allocation is 
"dirty" and so can be moved to more recently used places. These write gates slow 
the code down, but they speed up the GC even more, and so they are worth while.

The GO GC can also take advantage of always knowing exactly where all the GC 
pointers are, because there are only GC pointers. This enables a moving GC, 
which "compacts" fragmented memory.

When GC is optional, or used rather rarely, as in D, the write gate technique is 
a net loser. The GC is sped up at the cost of slowing everything else down. And 
since there are all kinds of pointers in D, one no longer can use a moving GC 
allocator, because it cannot know exactly where 100% of the GC pointers are.

If there was a way around these two issues, we would have found it by now. But 
by adding write gates, and making GC pointers the only pointers, D won't be 
systems programming language anymore.

So why does D have a GC at all?

1. It enables a killer feature - CTFE that can allocate memory. C++ doesn't do 
that. Zig doesn't do that.

2. Choice is nice. For example, I prefer to use the GC for initialization work, 
and the inner loop gets manual allocation. I get the best of both.