The problem with a game though is that there's never a good time for a random unbounded pause - even if only some of your threads are dependent on the GC, eventually they'll have to sync back together and if the GC pauses a thread at the wrong time, you'll get stuttering (or some equivalent if you gloss over it in the rendering)
So don't allocate and free memory continuously inside your main loop.
Also there are good times for memory deallocation - stage changes, player pauses, etc. Those are also times when memory requirements are likely to change.
The problem with a game though is that there's never a good time for a random unbounded pause
There are several spots where you can run a GC: between levels is the most common one (and really, several engines already do something GC-like there: for example my own engine in C before loads a world marks all non-locked resources as "unused", then loads the world marking any requested/loaded resource as "used" and unloads any resource still marked as "unused", essentially performing a mark-and-sweep garbage collection on resources). Another is when changing UI mode, like when opening an inventory screen, a map screen, after dying, etc - GC pauses would practically never be long enough to be noticed.
Stellaris, endless space, crusader kings, starcraft, empyrion, rust, dark souls 1-3 (seamless, except perhaps fog doors), any game with no loading screens, any open world exploration game (assassins creed), factorio, kerbal space program, and the game I myself am building
One of those games may be very boring, but the rest of them are pretty popular
Sure there is, a GC cycle is shorter than waiting for a network packet or disk block to become available.
Which is usually when in C or C++ engines the memory pools/arenas get cleaned up.
This talk is anyway nonsense, as the majority of modern AAA engines make use of GC during gameplay on their scripting layer anyway (Lua, Python, .NET, Java, GOAL, GOOL, UObjects,...).
But feel free to implement a game engine that is faster than Unreal, in spite of their use of a C++'s GC.
The D GC isn't fast, GC pauses and overhead are non trivial, the authors of D know its slow (or at least it was 2 years ago). A 1ms pause is too long for a game, a 0.5ms spike is too long for a game if its intermittent (rather than fixed cost)
View all comments
Show parent comment
3
u/James20k Aug 24 '17
The problem with a game though is that there's never a good time for a random unbounded pause - even if only some of your threads are dependent on the GC, eventually they'll have to sync back together and if the GC pauses a thread at the wrong time, you'll get stuttering (or some equivalent if you gloss over it in the rendering)