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

[Walter Bright]

On 10/29/2022 3:59 PM, Adam D Ruppe wrote:
> First, I proposed raw, not managed, let's be safe by default. Also remember what 
> `alias this` does; an unprotected pointer (aka raw!(T*)) can implicitly cast to 
> a protected pointer (aka T*). Third, think about what strcpy does. There's no 
> need to change that signature at all - it is exactly the same as it is now, 
> since it doesn't actually write to any pointers.

strcpy writes through its first parameter

> I'd assume managed by default - just like how arrays are bounds checked by 
> default. If the programmer gets lazy, they get the 1% performance penalty but 
> default protection. You have to opt out of the barrier with the `raw!T` (or the 
> command line argument to turn it all off).
> 
> And since the barrier is only meaningful to pointer writes, it is completely 
> useless with a const pointer because they are never written. So no need to draw 
> a distinction there at all. Moreover, writing *through* a pointer is not the 
> same as writing *to* the pointer. strcpy is writing to `char`s, not to `char*`, 
> so even the same code is generated anyway. You don't have to barrier a `char`, 
> the GC doesn't care if its value changes.
> 
> But even if it did write to the pointer, there'd be no need to change the 
> signature, since the raw pointer implicitly converts to the managed pointer. And 
> remember, the managed pointer only even generated different code if the *pointer 
> itself* is actually written to,

No, if what it points to is written, because that's what makes the target page 
"dirty".

> and moreover, we can even elide the checks if we 
> know it is pointing to the same block, since the GC won't care about 
> specifically where in the block it points, just that it points to the block. So 
> even `a = a[1 .. $];` need not use a barrier. (I think.)
> 
> Arguably, all C functions should take raw pointers, but if the reference is 
> borrowed, again it doesn't matter too much since you know there's another 
> reference at the call site. So you might get away with ignoring that detail too. 
> But still, the guiding principle is to be safe by default and allow people a 
> chance to opt out with explicit action. Just like bounds checking in principle.

In DOS programming, near pointer could always be converted to far. So why didn't 
everyone just use far APIs? A lot did. But it turns out, you could get a lot 
more performance by mixing near and far, at the cost of ugly code and a lot of 
careful work.

I was glad to leave all that behind.

Besides, if it was so easy to do, why has nobody produced a C compiler that uses 
a GC instead of malloc/free?

Microsoft implemented a raw/managed pointer type in C++/CLI, and it has set 
nobody on fire. It appears to be a dead end.