November 24, 2020
On 24/11/2020 12:50 AM, aberba wrote:
> On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole wrote:
>> On 23/11/2020 4:48 AM, Ola Fosheim Grostad wrote:
>>> So that means there are only three options left: single threaded GC pool, non-language GC or ARC.
>>
>> Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.
>>
> 
>> ...
>>
>> This is the direction I believe our default should be. It covers pretty much all use cases with reasonable performance.
> 
> Can you expand on this?

There isn't much to say.

We already have POSIX support done, just need to implement Windows now.

The basic gist of it is, you want to move the scanning + collecting to a separate concurrently executed thread. In a fork based model, that uses another process to do it. On Windows you would use another thread with a (non-changing) view of the memory of the process.

The reason I say it should be the default is: with multi-core systems being the default now, adding a dedicated thread for scanning + collecting isn't all that expensive and it allows to keep the main logic of the program running without any interruptions to the end user unless an OOM situation occurs.

But as Ola has said, there are down sides to this approach once you start needing performance.
November 23, 2020
On Monday, 23 November 2020 at 11:54:24 UTC, Paulo Pinto wrote:
> Other bad news is that if you don't want the runtime to look bad against tracing GC implementations,
>
> https://github.com/ixy-languages/ixy-languages
>
> You need to ship your own CPU with ARC specific improvments,
>
> https://blog.metaobject.com/2020/11/m1-memory-and-performance.html

Not exactly sure what you mean by this. Swift isn't really representative of what you can achieve with ARC. Swift is designed to be easy to use and compatible with Obj-C semantics.

ARC can also improve over time as more theory about shape analysis of heap patterns becomes available and you can gradually improve pointer analysis passes over time.

The key issue is to not provide the programmer with manual acquire/release or any way to access the ref count.

Also, in D owning!T would be nonatomic, and owning!shared(T) would be atomic unless the compiler can prove that it isn't shared yet.

My own on-paper language is ARC based.

Although for D, it would probably be better to add actors and limit actors from calling nogc code, then emit barriers for all gc code and use incremental collection. Incremental collection would be good for game-world collection as you could call it between iterations and specify it to complete in 5ms or something.

November 23, 2020
On Monday, 23 November 2020 at 12:10:27 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 23 November 2020 at 11:54:24 UTC, Paulo Pinto wrote:
>> Other bad news is that if you don't want the runtime to look bad against tracing GC implementations,
>>
>> https://github.com/ixy-languages/ixy-languages
>>
>> You need to ship your own CPU with ARC specific improvments,
>>
>> https://blog.metaobject.com/2020/11/m1-memory-and-performance.html
>
> Not exactly sure what you mean by this. Swift isn't really representative of what you can achieve with ARC. Swift is designed to be easy to use and compatible with Obj-C semantics.
>
> ARC can also improve over time as more theory about shape analysis of heap patterns becomes available and you can gradually improve pointer analysis passes over time.
>
> The key issue is to not provide the programmer with manual acquire/release or any way to access the ref count.
>
> Also, in D owning!T would be nonatomic, and owning!shared(T) would be atomic unless the compiler can prove that it isn't shared yet.
>
> My own on-paper language is ARC based.
>
> Although for D, it would probably be better to add actors and limit actors from calling nogc code, then emit barriers for all gc code and use incremental collection. Incremental collection would be good for game-world collection as you could call it between iterations and specify it to complete in 5ms or something.

It is always about theory, in practice tracing GC always wins.

While we are on the subject Herb Sutter's talk on C++ deferred pointers talk at CppCon (aka tracing GC, as he points out half way through the talk).

https://www.youtube.com/watch?v=JfmTagWcqoE

https://github.com/hsutter/gcpp

A design that influenced C++/WinRT, which uses background threads and clever uses of modern C++ to reduce the impact of RC on program performance. Still they are slower than tradicional .NET/Win32 applications.
November 23, 2020
On Monday, 23 November 2020 at 12:36:07 UTC, Paulo Pinto wrote:
> It is always about theory, in practice tracing GC always wins.

That really depends, but a tracing GC is easier to use, as it catches cycles. So it would be better to have an incremental collector.

But I don't think D can get there within 5 years, and do people want to discuss what D could have in 5 years?  I think we need to figure out what the time frame should be.

You could get non-optimized ARC in 6 months.
And basic optimized ARC in 12 months.
Optimized ARC in 18 months.
Opiimized ARC with borrow checker in 24 months.

That is a lot more attractive IMO.

Open Source should focus on strategies which can be done as small incremental steps and ARC can be made compatible with std::shared_ptr when it is allocated with std::make_shared. That is a big plus.




November 23, 2020
On Monday, 23 November 2020 at 12:05:14 UTC, rikki cattermole wrote:
> But as Ola has said, there are down sides to this approach once you start needing performance.

Rikki, I want to add that I don't argue that it shouldn't be the default.  I was arguing in the context of games and other demanding low latency, high memory, computation applications.

Your fork-collector could be excellent for most GUI applications that are mostly based on D code. For instance, a GUI application can detect that the user is inactive and trigger a fork.

It could also work for turn-based games.



November 24, 2020
On 24/11/2020 1:58 AM, Ola Fosheim Grøstad wrote:
> On Monday, 23 November 2020 at 12:05:14 UTC, rikki cattermole wrote:
>> But as Ola has said, there are down sides to this approach once you start needing performance.
> 
> Rikki, I want to add that I don't argue that it shouldn't be the default.  I was arguing in the context of games and other demanding low latency, high memory, computation applications.
> 
> Your fork-collector could be excellent for most GUI applications that are mostly based on D code. For instance, a GUI application can detect that the user is inactive and trigger a fork.
> 
> It could also work for turn-based games.

Its not actually my idea. Rainer has already done an implementation :)

http://rainers.github.io/visuald/druntime/concurrentgc.html
November 23, 2020
On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole wrote:

> Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.

FYI, `fork` is not available on iOS, tvOS and watchOS.

--
/Jacob Carlborg
November 23, 2020
On Monday, 23 November 2020 at 13:09:31 UTC, rikki cattermole wrote:
> Its not actually my idea. Rainer has already done an implementation :)
>
> http://rainers.github.io/visuald/druntime/concurrentgc.html

Alright! So now we need a high quality portable GUI framework that also can be used for turn based games.

There is a push for simple games in Flutter. Maybe possible to "steal" their codebase.

November 23, 2020
On Monday, 23 November 2020 at 13:29:58 UTC, Jacob Carlborg wrote:
> On Monday, 23 November 2020 at 03:15:59 UTC, rikki cattermole wrote:
>
>> Concurrent GC (aka fork) and concurrent DS GC with i.e. fork.
>
> FYI, `fork` is not available on iOS, tvOS and watchOS.

On iOS you probably should use ARC. LLVM IR has ObjC ARC support.


November 24, 2020
On 24/11/2020 2:31 AM, Ola Fosheim Grøstad wrote:
> Alright! So now we need a high quality portable GUI framework that also can be used for turn based games.

I'm working on it.

Problem is I'm starting all the way back at colorimetry. A fascinating deep subject that pretty much every organization in the industry has their own thing on (as I say, you implement a dozen color spaces and now you need to implement two dozen more).