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

[Bruce Carneal]

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

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

 From https://go.dev/blog/ismmkeynote "Getting to Go: The Journey 
of Go's garbage collector" I gather that the initial goal of 
general compacting was abandoned and that the purpose of the 
write barriers is to maintain tri-color invariants 
(white/black/gray) when the GC is active.

Perhaps I've misunderstood something?