Apropos recent discussion, here is a serious question: would you pay for either of these?

- High-throughput/scalable gc.  High sustained allocation rates, large heaps, many cores, compacting&generational

- Concurrent gc.  No pauses

On Tuesday, 25 January 2022 at 03:37:57 UTC, Elronnd wrote:
> Apropos recent discussion, here is a serious question: would you pay for either of these?
>
> - High-throughput/scalable gc.  High sustained allocation rates, large heaps, many cores, compacting&generational
>
> - Concurrent gc.  No pauses

I'd pay to have it removed and replaced with ARC.

GC in it's current form can not compete with other more performant GCs and it shouldn't. D is in a unique position to enable people to write code as if they're writing python and also accommodate them when they want to do low-level optimizations.

If we could just have automatic reference counting both the GC and No-GC people would be happy. It's okay if that route changes how pointers work (metadata would have to be added and some code would break), this is the right move in the long run.

On Tuesday, 25 January 2022 at 06:13:31 UTC, Random Dude wrote:
> GC in it's current form can not compete with other more performant GCs

I think it can, for reasons I've explained elsewhere.  But that's a bit beside the point; the question is: what _would_ you do _if_ it could?

> D is in a unique position to enable people to write code
> as if they're writing python and also accommodate them
> when they want to do low-level optimizations.

Fast AND expressive is a much sexier value proposition than fast XOR expressive.

On Tuesday, 25 January 2022 at 06:13:31 UTC, Random Dude wrote:
> On Tuesday, 25 January 2022 at 03:37:57 UTC, Elronnd wrote:
>> Apropos recent discussion, here is a serious question: would you pay for either of these?
>>
>> - High-throughput/scalable gc.  High sustained allocation rates, large heaps, many cores, compacting&generational
>>
>> - Concurrent gc.  No pauses
>
> I'd pay to have it removed and replaced with ARC.
>
> GC in it's current form can not compete with other more performant GCs and it shouldn't. D is in a unique position to enable people to write code as if they're writing python and also accommodate them when they want to do low-level optimizations.
>
> If we could just have automatic reference counting both the GC and No-GC people would be happy. It's okay if that route changes how pointers work (metadata would have to be added and some code would break), this is the right move in the long run.

ARC will also not compete, unless one goes the extra mile of making the compiler ARC aware, elide retain/release calls, do cascade deletions in background threads, take care on cascade deletions to avoid stack overflows on destructor calls, provide multicore friendly versions of them,.....

If you are paying to replace GC with ARC, without putting the money to reach Swift level of performance (which is still pretty lame versus last gen tracing GCs in Java/.NET), then you will be getting lemons.

https://forums.swift.org/t/a-roadmap-for-improving-swift-performance-predictability-arc-improvements-and-ownership-control/54206

I can already see it, the forums being inundated with complains about ARC performance versus other languages.

On Tuesday, 25 January 2022 at 07:13:41 UTC, Paulo Pinto wrote:
> ARC will also not compete, unless one goes the extra mile of making the compiler ARC aware, elide retain/release calls, do cascade deletions in background threads, take care on cascade deletions to avoid stack overflows on destructor calls, provide multicore friendly versions of them,.....

Indeed.  See Bacon et al, 'Unified Theory of Garbage Collection': increasingly sophisticated RC approaches tracing (and vice versa).  So it's a bit strange to assume we can do one but not the other.  And tracing makes a better starting point due to the generational hypothesis.

On 25/01/2022 8:22 PM, Elronnd wrote:
> On Tuesday, 25 January 2022 at 07:13:41 UTC, Paulo Pinto wrote:
>> ARC will also not compete, unless one goes the extra mile of making the compiler ARC aware, elide retain/release calls, do cascade deletions in background threads, take care on cascade deletions to avoid stack overflows on destructor calls, provide multicore friendly versions of them,.....
> 
> Indeed.  See Bacon et al, 'Unified Theory of Garbage Collection': increasingly sophisticated RC approaches tracing (and vice versa).  So it's a bit strange to assume we can do one but not the other.  And tracing makes a better starting point due to the generational hypothesis.

RC shines for when deterministic destruction is required.

So that is when you have any external resource bound to a D type.

But it is horrible as a language default. Not all types like say a pointer or a slice should be bound to any sort of memory management strategy in a native language.

It is very expensive compared to a GC. Due to the constant cache invalidations going on.

I want to get RC properly in D without having to rely on a struct wrapper. That way the compiler can know that eliding of calls can take place. Plus if its in the language, we can get const string type too with classes and all!

On 25/01/2022 10:23 PM, Ola Fosheim Grøstad wrote:
> On Tuesday, 25 January 2022 at 07:13:41 UTC, Paulo Pinto wrote:
>> If you are paying to replace GC with ARC, without putting the money to reach Swift level of performance (which is still pretty lame versus last gen tracing GCs in Java/.NET), then you will be getting lemons.
> 
> With per fiber/task/actor ownership + unique_ptr you reduce the need to increase the refcount significantly.

With scope without ref or return it may even be possible to elide all calls to reference counting except for the last decrement.

On Tuesday, 25 January 2022 at 08:24:22 UTC, rikki cattermole wrote:
>
> On 25/01/2022 8:22 PM, Elronnd wrote:
>> On Tuesday, 25 January 2022 at 07:13:41 UTC, Paulo Pinto wrote:
>>> ARC will also not compete, unless one goes the extra mile of making the compiler ARC aware, elide retain/release calls, do cascade deletions in background threads, take care on cascade deletions to avoid stack overflows on destructor calls, provide multicore friendly versions of them,.....
>> 
>> Indeed.  See Bacon et al, 'Unified Theory of Garbage Collection': increasingly sophisticated RC approaches tracing (and vice versa).  So it's a bit strange to assume we can do one but not the other.  And tracing makes a better starting point due to the generational hypothesis.
>
> RC shines for when deterministic destruction is required.
>
> ...

That is the naive idea, until a cascade deletion of a graph based datastructure happens.