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

[Walter Bright]

On 10/29/2022 5:18 AM, Adam D Ruppe wrote:
> On Saturday, 29 October 2022 at 10:35:21 UTC, Walter Bright wrote:
>> I've pointed out the problems with two hierarchies of pointers many times.
> 
> D already has several kinds of pointers. T*, const(T)*, shared(T)*. I don't see 
> how unmanaged(T*) is any different.

Consider:

      strcpy(char* p, const(char)* q)

Now consider managed:

      strcpy(char* p, const(char)* q)
      strcpy(char* p, managed(const(char)*) q)
      strcpy(managed(char*) p, const(char)* q)
      strcpy(managed(char*) p, managed(const(char)*) q)

It's quite different.


> In fact, I sketched up some thoughts i might put in the blog monday but the 
> short of it is you could:
> 
> * -ptrcheck=[none|barrier] argument to the compiler, similar to how -checkaction 
> and -boundscheck can be modified.
> 
> * all pointer writes assumed to be barriered except ones marked 
> raw/unmanaged/whatever, which is a qualifier similar to const and shared
> 
> * the raw pointer would essentially be struct raw(T) { T it; alias it this; void 
> opAssign(T rhs) { barrier(); it = rhs; } }
> 
> * possible optimizations would be eliding the barrier in cases like `a = a[1 .. 
> $]` because you know - thanks to the bounds check - that this refers to the same 
> memory block anyway and is thus irrelevant to the GC wrt marking. I guess it can 
> be trouble if it wants to move tings in the middle of the slice operation though.
> 
> 
> I'm not convinced this is impossible.

It's not impossible. It's more like what is the cost/benefit.


> (btw im also not convinced it is necessary, i think D's gc is good enough as it 
> is.)

So do I. Isn't it ironic that people complain about D because it has a GC, and 
complain about D because the GC does not slow down non-GC code? I'm terrible at 
marketing.