Comment by tapoxi
19 hours ago
GDScript in Godot doesn't use GC, it uses reference counting and doesn't "stop the world".
Other languages that bind into the engine do this too, (C++, SwiftGodot, Rust-Godot)
C# obviously does, Miguel de Icaza actually started SwiftGodot because he (ironically) ended up hating GC pauses after promoting C# for so long
Go does surprisingly well at keeping GC freezes to a minimal in a way that you're unlikely to notice... C# has gotten a lot better since the core split as well. That said, there's a lot that comes down to how a developer creates a game.
I was added late to a project working on a training simulation engine, similar to games, where each avatar in the game was a separate thread... man, the GC pauses on the server would sometimes freeze for literally 10-15s, and it was not good at all. I refactored it to use an event-loop model and only 2 other threads, which ran much better overall. Even though it wasn't strictly a game itself, the techniques still matter. Funny how running through a list of a few hundred things is significantly better than a few hundred threads each with their own timers, etc.
> Funny how running through a list of a few hundred things is significantly better than a few hundred threads each with their own timers, etc.
State machines are not in fashion. Exposed event loops are not in fashion. Most frameworks do their damnedest to hide those components.
As for GC freezes, if you're doing a game like project you can always just allocate a few huge arrays at startup and reuse those with no deallocation/allocation in most garbage collected environments.
> C# has gotten a lot better since the core split as well.
It has improved but the majority of games using C# are using Unity which does not use .NET (Core). It uses Mono or IL2CPP specifically with the Boehm GC so it performs significantly worse than .NET and even standalone Mono (SGen GC).
[dead]
Reference counting is a GC algorithm from CS point of view, as looking into any worthwhile reference will show.
It's not what people mean when they say GC though, especially in reference to games, where you care about your peak frame time more than about your average frame time.
Reference counting can also have very bursty performance. Consider what happens when you decrement the last reference to an object which is the sole remaining reference to an entire large tree of other objects. This will trigger a whole cascade of subsequent decrements and deallocations, which can be arbitrarily large.
Of course, you might say, "Well, sure, but your reference counting implementation doesn't need to eagerly deallocate on dereference." That's true! You can write a ref counter that defers some of those deallocations or amortizes them across multiple operations.
And when you do that, now you really do have a garbage collector.
See: https://web.eecs.umich.edu/~weimerw/2008-415/reading/bacon-g...
People should learn their subjects properly, not street knowledge.
You should watch some of the more recent Gamers Nexus videos... the average frame pacing counts for a lot, and they're making a concerted effort to show this, as it does represent the level of "jank" in games very well.
2 replies →
I haven't dug deep enough into C# to say this with certainty, but I believe later C# versions allows you to do enough manual allocation to "almost" get around the garbage collector. As well as new calls to try and nudge the GC away from hot paths.
You need to be very disciplined to pull this off, though. LINQ is basically off limits, for example. And of course, Godot's C# is likely much older than these modern techniques to begin with.
Godot's C# is fairly recent, C#12/.NET 8.
That's good to know. So it probably has the capability if you really wanted to dig in.
But that effort on an active engine would quite a long time to comb through. Really comes down to if a highly invested contributor wants to push it through and gets the go ahead.
Yes, as long as you're not using Godot 3.x. Some still use 3.x (Mono) because 4.x (.NET) does not support web exports.