Why is D's GC slower than GO's? (page 9)

On Saturday, 29 October 2022 at 12:05:40 UTC, IGotD- wrote: > On Saturday, 29 October 2022 at 11:59:24 UTC, Imperatorn wrote: >>> >>> Your analogy with bizarre addressing modes and HW limitation of early x86 processors doesn't make any sense. Also, the design with far/near pointers in those compilers is questionable and further fuels the point that pointers need to be opaque and the compiler should deal with such mess. >>> >>> [...] >> >> What solution do you propose? > > For D or ancient C compilers? For D

On Saturday, 29 October 2022 at 12:37:52 UTC, Imperatorn wrote: > On Saturday, 29 October 2022 at 12:05:40 UTC, IGotD- wrote: >> >> For D or ancient C compilers? > > For D I suggest a "built in" raw pointer type and a managed pointer type. The raw pointer type should not be used in safe D programming because safe D relies on garbage collection. The entire druntime/phobos should be changed in order to use the managed pointers instead for any raw pointers (unless special cases). The functionality of the managed pointer type should be able to be completely customized in order to support all sorts of different GC algorithms.

On Friday, 28 October 2022 at 10:23:16 UTC, AnimusPEXUS wrote:

On Friday, 28 October 2022 at 09:51:04 UTC, Imperatorn wrote:

Hi guys,
Is D really that bad?

D isn't bad. D is good. it's just needs many bugfixing and more stability (without which it's complicated to even advertise it to use it for prod) and also it needs more stable and maintained tools (frameworks) for many things, like bindings for wayland and better wasm/wasi support. and more interesting things, like docker/kubernetes does for Go.

Also, I'm trying here to figure out how to write wasm runtime support (yes, I know about adr's one), and I think there should be better documentation/api generator/browser, like golang's/python's godoc/pydoc servers.

What about this?

https://wiki.dlang.org/Generating_WebAssembly_with_LDC

On Saturday, 29 October 2022 at 10:04:01 UTC, IGotD- wrote: > On Saturday, 29 October 2022 at 09:42:32 UTC, Walter Bright wrote: >> >> It's literally impossible for me to stop anyone who wants to improve the GC. It's all open source, and Boost licensed. It's even designed to be pluggable. > > No they can't because D doesn't have a built in managed pointer type and they are limited to a subset of GC algorithms (even limited among the tracing GC ones). > > It is possible to use a library custom GC type but then runtime/phobos don't use these so replacing the GC in the entire program isn't possible. > > Many have tried to explain this numerous times but you just ignore this obvious fact. If you're changing the compiler to add a different GC strategy, you can add managed pointers.

On Saturday, 29 October 2022 at 10:17:13 UTC, Imperatorn wrote: > What would be some theoretical ways to improve? > > For example, adding a custom gc type, are we talking months or work? Years? What would it look like? Sorry for being ignorant on this The post currently is unavailable, but maybe some google cache or time-machine could find it: https://news.ycombinator.com/item?id=14592457

On Friday, 28 October 2022 at 21:11:00 UTC, H. S. Teoh wrote: > On Fri, Oct 28, 2022 at 08:41:13PM +0000, Ali via Digitalmars-d wrote: [...] >> [...] > > Maybe, just maybe, D does a lot of things right, in spite of doing a few > things wrong (that people love to pick on and complain about)? ;-) > > [...] Maybe some of them do like it a lot, and that is the reason they complain. They are just dishonest with themselves, in the forum.

October 29, 2022

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

Posted by Walter Bright
in reply to Adam D Ruppe

Permalink

Walter Bright

Posted in reply to Adam D Ruppe

Permalink

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.

Forums