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

[Piotr Duda]

On Saturday, 29 October 2022 at 04:46:21 UTC, Walter Bright wrote:
> 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.

If by "write gates" You mean additional code generated for every 
write, then you don't need it, You can use GetWriteWatch (on 
windows) or mprotect and signal handling (on linux, and probably 
other posix compliant OSes) to get list of modified pages on GC 
heap.

> 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.

You don't need to know where **all** GC pointers are (in the 
sense that you know if something is pointer or not), if You don't 
know if something is pointer or not (because for example it's 
part of union) just pin pointed object to prevent it from being 
moved.

> 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 since there is no need to add write gates and making GC 
pointers the only pointers, it should be possible.