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

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Mon Nov 23 12:10:27 UTC 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.



More information about the Digitalmars-d mailing list