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

What you are going to hear is "I'd like someone else to do a bunch of work, and if it benefits me, I'll think about using it."

If you're serious about this, you should put together an extensive set of numbers demonstrating clear failure of D's garbage collector, failure of existing D solutions, and well-defined opportunities for improvement.

On Tue, Jan 25, 2022 at 02:24:48PM +0000, bachmeier via Digitalmars-d 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
> 
> What you are going to hear is "I'd like someone else to do a bunch of work, and if it benefits me, I'll think about using it."
> 
> If you're serious about this, you should put together an extensive set of numbers demonstrating clear failure of D's garbage collector, failure of existing D solutions, and well-defined opportunities for improvement.

+1.  Around these parts I hear a lot of complaints about GC this, GC that, but I've yet to see actual performance measurements that show just how bad the GC is.  It would be nice to see some actual numbers (and the actual code where the bad GC performance happens) that would show us just where D's GC is not up to the task, so that we have a concrete way of measuring any progress (or lack thereof) made on the GC.


T

-- 
The only difference between male factor and malefactor is just a little emptiness inside.

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

No I wouldn't pay for any of those because that's not where the problem lies.

The problem is that the maintainers refuse to realize that the language/runtime are too limited and cannot support any of the proposed GC types.

D has two options, either add a managed pointers in the language or use library pointer types types (like C++, unique_ptr etc). Problem is that the runtime and standard library also needs to be changed in order to support switching GC types depending on wich route they take.

After the D project adds the necessary additions to support plug and play GC types, new GC types will emerge naturally as many people with start to tinker with new GC types.

After reading my book on GC, you're kinda right.

Right now a generational GC wouldn't be possible in D due to not having write barriers.

However this is not a language limitation and can be freely added to the compiler implementation as an opt-in solution. The GC interface of course is also freely modifiable and would too need to be modified.

Right now there is only two sort of wins I can see being possible.

1) Make the current conservative GC support snapshotting for concurrency on Windows.
2) Support a task/fiber aware GC. This will kinda give us a generational GC, without actually being a generational GC.

Either way, still no reason to think we need to change the language to make more advanced GC's possible.

Just to be clear, that book clearly states that a generational GC is not always the best solution. It is not worth complicating the language by adding a whole new pointer type just to make this possible even if it was required (which it absolutely isn't).

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.

In a small code base it might but in larger SW RC is on par with GC because it is impossible to keep track of all the references. You end up with leaks and dangling shared_ptrs because someone has a ref ... somewhere.

The best option in a large code base is RAII with value types until you cannot and then rely on unique_ptr equivalents that can only have a single owner at any one time (without hackery). Only RC/shared_ptr when you absolutely must have multiple owners and even then interrogate your design.

On Wed, Jan 26, 2022 at 02:09:24AM +0000, Tejas via Digitalmars-d 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.
> > 
> > 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.
> 
> Even then people are dissatisfied, apparently.
> 
> I asked Reddit why ARC isn't used more widely despite Swift being so successful and was **swiftly**(pun intended 😉) corrected that Swift user share has become 50% of what it once was at it's peak.
[...]

Cognitive dissonance. :-P


T

-- 
Try to keep an open mind, but not so open your brain falls out. -- theboz

On Wednesday, 26 January 2022 at 00:03:26 UTC, rikki cattermole wrote:
> After reading my book on GC, you're kinda right.

Thanks for the show of confidence :)


> 2) Support a task/fiber aware GC. This will kinda give us a generational GC, without actually being a generational GC.

Thread-local gc is a thing.  Good for false sharing too (w/real threads); can move contended objects away from owned ones.  But I see no reason why fibre-local heaps should need to be much different from thread-local heaps.

One java implementation used the high bits of the stack pointer as a thread identifier/tls pointer/etc.

I would like to see adaptive nursery size.  Good for non-fibre-based web stuff, also e.g. video games.  Imagine: you tell the GC every tick/request, and it tunes nursery size to 99%ile allocation size per frame.  Actual GC is pretty much free since all the stuff you allocated over the course of the frame is gone.  Then you have all the safety of the full GC approach, and nearly all the performance of the manual arena approach (and much better than malloc/free).