On Tuesday, 25 January 2022 at 07:22:36 UTC, 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.

Only if you take the "deferred" RC route, which Swift/Rust/C++/Nim do not! Without the "deferred" aspect RC remains quite a different beast. Different algorithm, different runtime profiles, different memory consumptions, enables different optimizations and of course different problems.

On Tuesday, 25 January 2022 at 09:42:25 UTC, Araq wrote:
> On Tuesday, 25 January 2022 at 07:22:36 UTC, 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.
>
> Only if you take the "deferred" RC route, which Swift/Rust/C++/Nim do not! Without the "deferred" aspect RC remains quite a different beast. Different algorithm, different runtime profiles, different memory consumptions, enables different optimizations and of course different problems.

Indeed, that was kind of my point, unless one is willing to invest the required resources, a bit like you guys are doing with Nim, a RC implementation will not magically outperform modern tracing GC, only naive implementations of tracing GCs.

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

If it was delivered the foundation would probably be happy to give at least some money (not that we have an unlimited supply), on the condition that it were open-sourced.

Speaking as a user of D, I wouldn't use a forked compiler should one be required.

On Tuesday, 25 January 2022 at 10:19:48 UTC, max haughton 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
>
> If it was delivered the foundation would probably be happy to give at least some money (not that we have an unlimited supply), on the condition that it were open-sourced.
>

A contract for this sort of work is always a possibility. That's what the HR fund is for:

https://www.flipcause.com/secure/cause_pdetails/NTUxOTc=

Anyone serious about doing a project like this (any relatively complex project, not just a new GC) can get in touch and we can discuss it. I'm not saying the foundation *would* pay for any particular project, but the discussion and possibly a meeting could lead to that if agreement is reached that it's worth doing.

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?

No. D's GC is already plenty good enough right now.