On Wednesday, 18 May 2022 at 14:40:59 UTC, ryuukk_ wrote:
The concept of GC is fine, it exist in both Unreal and Unity
The only difference is their implementation
Both Unreal/Unity doesn't have "much" problems because they use
some sort of incremental GC, usually multithreaded
The problem of D is it's the worst implementation for games, it
scans your entire heap, while doing so pauses all the threads
The bigger your heap is (wich games usually have), the longer
the pause will be
It's not a problem for "some" games, but as 144hz monitors are
becoming mainstream, the need of games running at 120/144fps is
becoming crucial
For 120fps, your frame budget is only 8ms, no time for any GC
pause
Even thought GC's story is better on Unreal/Unity, they still
struggle, constantly, wich GC issues, a simple google request
is enough to validate the point)
I used to not care about the GC, until it started to get in my
way, since then, malloc/free/allocators, and nothing else
Designing an engine this way gives you much more control, GC
for scripting only in isolated thread!
That's why it is dangerous to tell people to not mind the GC
and "just program", no, you have to be meticulous about your
allocation strategy to properly make use of the benefits that a
GC will give you!
GC is an ice thing, when used properly, depending on its
implementation!
Thanks for the insight here, very informative. I think the hybrid
approach works fairly well for my engine's use case, though I get
what you are saying about the heap size and all that, I suppose
some games may not be able to avoid that issue without taking the
manual approach.
Also, I know that D has some sort of interface for allowing
custom GC implementations -- has anyone ever made a functional
alternative? Something that takes the incremental approach that
you mentioned as opposed to the pause and scan method?
