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

[Guillaume Piolat]

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

Yes.

I've been working on fast programs all my professional life.
Say you want top performance.
You would go ASICs.
But it's impractical so you could go FPGA.
But it's impractical so you could go GPGPU.
But it's impractical so you decide to go native.

One already traded a lot of speed for convenience, and THEN 
decide one need every last performance bit. This is a _common_ 
scenario, though not necessarily a reasonable one.

So let's say you were tasked to make one program as fast as 
possible, native on the CPU.

Seen from afar, this GC thing will be a tiny blip on the radar of 
everything that could make your program a bit slower: disk 
caches, network, memory bandwidth, maxing threading, compiler 
bugs... and of course the much larger risk of breaking the 
program with failed optimizations.

It is easy to make things fast even with the D GC. You just have 
to optimize if it is a problem, move it out of GC. Grow buffers, 
use realloc(), etc. It is the same you would have done in other 
native languages. This doesn't just rule out the stdlib, it also 
rules out almost any other library not written with the 
performance goal.

Thankfully we have @nogc, -betterC, -profile=gc, and whatnot. 
AFAIK people of D are using to push the boundaries and have fast 
things. I would wager it's not the biggest challenge of all to 
deal with the GC - or to avoid it. Perhaps harder in a team?

The GC is an extension that allows programs that can afford a GC 
(most) to be written faster.

It is the default, because most programs don't begin their lives 
with a need to be fast, or correct, but mostly to be written 
quickly! always-has-been.gif

Write gates are inherently "not-native", like integer overflow 
checks and boundscheck that you can't remove. It is one more 
invariant to maintain for the system programmer, for something 
that would couple things way beyond the druntime it was made for. 
It is surprising it is pushed so often with zero use cases.