Garbage Collection and gamedev - tl;dr Yes we want it, so let's solve it
pjmlp at progtools.org
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
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
More information about the Digitalmars-d