Garbage Collection and gamedev - tl; dr Yes we want it, so let's solve it
gooberman at gmail.com
Sun Nov 22 14:30:45 UTC 2020
There's many nuanced points to consider here, so given that GC
came up on the live Q&A and I got in to a bit of a chat there I
figured copy/pasting that log and getting in to a (real,
stop-saying-gamedev-doesn't-want-this) longer form discussion
about the exact kind of GC we want in game development.
There's a few people in the community here that are involved in
console game dev, and they would know the kind of characteristics
we require. Similarly, many of the lower level programmers that
work with GPUs and the like are well aware that garbage
collection is not good enough for releasing resources outside of
the main system environment and would know the kind of control we
require over deallocation and release paths.
The short form of my view is that we are actively using GC in
game dev at all levels. The largest commercial AAA engine has
been garbage collecting since the 90s (and go deeper, the
original Doom garbage collected). But as we scale up to massively
parallel execution across all forms of programming, the
monolithic program-halting mark and sweep GC that comes with D is
not good enough.
I've not yet sat down to do the full research in to the subject
that it demands, but I have ideas on what I want to look at.
Conversation copied to below:
I want to write a task-based GC, that will handle
destruction/deallocation as a task when the last reference to a
section of memory is unacquired
is freeing memory that costly in D?
The advantage of a collector is that it's a batch process
And computers LOVE batch processes
But in gamedev, we need a bit more immediate control at times
no I mean, it just feels like you're optimizing the fastest part
of the process
ya'll are really sensitive to question marks ending a line 🙂
The collector blocks the program currently. That's bad for
And yes, we do have Unreal Engine as the most direct example
that does exactly this
Anyone saying "gamedev doesn't GC" isn't paying attention
We just want a better solution
the collector blocks the program, but it blocks for scanning,
and task-based doesn't speed that up, right?
No, it's not about speeding it up at that point. It's about not
blocking anything else from running
right but mark phase has to block inherently, unless you get
really clever with your design or get hardware support
This is an extra advantage of the pointer acquire/unacquire
runtime hooks that I want. It's a bit more code, but it also
negates the need to do any kind of sweep
And it is something that should be opt-in, yeah. If your GC
doesn't define the hooks, then the code gen shouldn't try to
Pay as you go functionality!
I don't know the background of that, but yeah, I don't know how
the relative cost of mark and sweep is, if sweep is using a lot
of the fraction than speed it up by all means
I love GC 🐱🏍
More information about the Digitalmars-d