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