3 ms·
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++, SwiftGo
by tapoxi 11mo 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
- pjmlp 11mo agoReference counting is a GC algorithm from CS point of view, as looking into any worthwhile reference will show.
- furyofantares 11mo agoIt'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.
- tracker1 11mo agoYou 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.
- furyofantares 11mo agoGot a link? I can't work out which ones you're referring to.
- starkparker 11mo agomost recently https://www.youtube.com/watch?v=qDnXe6N8h_c https://www.youtube.com/watch?v=qDnXe6N8h_c on why FPS is flawed specifically for GPU benchmarking most specifically, an ongoing attempt to understand and debunk frame generation (DLSS, etc.) as a performance gain due to introducing latency despite high FPS: https://www.youtube.com/watch?v=Nh1FHR9fkJk https://www.youtube.com/watch?v=Nh1FHR9fkJk, https://www.youtube.com/watch?v=GDvfIbRIb3U https://www.youtube.com/watch?v=GDvfIbRIb3U More broadly than frame pacing, https://www.youtube.com/watch?v=Fj-wZ_KGcsg https://www.youtube.com/watch?v=Fj-wZ_KGcsg is a recent example of one of _many_ interviews going back years on why both frame times and frame rates are all flawed for explaining why some games feel smoother/lag more than others (there are GN videos dating back to 2016 on the subject)
- munificent 11mo agoReference 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-garbage.pdf https://web.eecs.umich.edu/~weimerw/2008-415/reading/bacon-g...
- pjmlp 11mo agoPeople should learn their subjects properly, not street knowledge.
- deleted 11mo ago[deleted]
- tracker1 11mo agoGo 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.
- Rohansi 11mo ago> 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).
- neonsunset 11mo ago[dead]
- nottorp 11mo ago> 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.
- johnnyanmac 11mo agoI 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.
- tapoxi 11mo agoGodot's C# is fairly recent, C#12/.NET 8.
- johnnyanmac 11mo agoThat'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.
- Rohansi 11mo agoYes, 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.