Garbage Collection and gamedev - tl;dr Yes we want it, so let's solve it

Paulo Pinto pjmlp at
Mon Nov 23 12:36:07 UTC 2020

On Monday, 23 November 2020 at 12:10:27 UTC, Ola Fosheim Grøstad 
> 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,
>> You need to ship your own CPU with ARC specific improvments,
> 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).

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.

More information about the Digitalmars-d mailing list