It's interesting to hear do you use D's GC? Or do you use your own custom memory management structure?

How performant is GC?

The reason I'm asking is I'm planning to dive into 3D game dev with D as a hobby in an attempt to create a game I dreamed of since I was a kid. I'd like to know if GC is worth using at all, or should I go with 100% manual memory management.

Any opinion is appreciated. Thanks in advance.

On Sunday, 1 August 2021 at 08:54:05 UTC, Kirill wrote:

I think both approaches are viable. I am making a small 3D game engine in D and I never had many issues with GC performance. In a game, you shouldn't be allocating a lot of stuff on the heap anyway. Most of big objects like buffers, textures should be initialized once during startup anyway. Things like matrices and vectors which you'll be using often are value types so they won't be going through GC anyway.

Just avoid things like particle emitter having 10000 particles which are GC-allocated whenever they spawn. Just make an 10000-sized array of particle structs and do the swap-with-last then reduce count by 1 trick.

But if you want to go manual memory management, D will allow you to do it.

On Sunday, 1 August 2021 at 08:54:05 UTC, Kirill wrote:

Often. I could avoid it but it's rarely worth it. Well, I do try to avoid heap usage in general when I can easily do so, but I don't often use RAII, let alone malloc/free. And even when I have done so, it's not so much for performance, it's for portability (through with Dylan Graham's LWDR I'm not sure I have to avoid GC for portability anymore).

Most people nowadays use an already made game 3D engine - You may well have heard of Unity and Unreal engine. While they do not let a game to be as performant as with a purpose-built engine, the fact that reasonably light 3D games have been made with them for ages speaks a lot.

Godot game engine is a great choice IMO, especially with D. It's fully open source, has a good D binding, and it has a better object model than Unity does. Binding here: https://github.com/godot-d/godot-d.

And yes, D GC is available with Godot. It's unlikely you'll have problems with it, as the game engine takes care of the heavy crunching - you generally write only the scripts.

You may also consider Dagon (https://code.dlang.org/packages/dagon). As a much smaller project it's going to be harder to use it than Godot, but if you want a pure D game engine you might consider it. It's still definitely an easier route than writing your own engine.

On Sunday, 1 August 2021 at 08:54:05 UTC, Kirill wrote:

There is one question I have, let's say you have a big game that uses several gigabytes of RAM. The objects are just allocated once with the GC but once you touch the GC like doing a new (which can be done by a library function), will the GC then start to scan all those gigabytes of data?

On Sunday, 1 August 2021 at 08:54:05 UTC, Kirill wrote:

In short, treat GC allocated memory the same way you would treat memory allocated and deallocated with malloc and free. For example, in C++ would someone who knows what they're doing allocate memory for large numbers of individual entities, like particles, in inner loops? No. They would preallocate. Do the same in D.

The GC isn't going to run a collection behind your back. It's only going to run if you do something that triggers an allocation. @nogc on the functions that are called in your inner loops will make sure you don't trigger a collection at the wrong moment. You have other tools if you need them (emphasis on if you need them), like pausing the GC, or invoking collection runs manually at specific points. This is the sort of thing you dig into if you find the GC is problematic.

I'm going to go out on a limb and say the odds are low that the GC will be a problem for you, and lower still if you are smart about using it. There is a class of games and other applications for which GC is certainly going to be problematic no matter how smart the developer is about using it, but I doubt anyone working on a hobby 3D is going to be anywhere near there. Even going full-on GC and being dumb about using it is going to be just fine for many kinds of games. It's all about the scope of the project and your allocations patterns. I mean, you can be less smart about it for games like Pac-Man, Galaga, etc, but you'll need to think about it more for something like Skyrim. Plan your allocation patterns in a way that makes sense for the game you are making.

To do that, just follow some simple rules. If it doesn't need to be a class, make it a struct. If it can be allocated on the stack, then don't use new. If there's something that needs heap allocation but you can see a way to easily manage it deterministically, then allocate with malloc instead of the GC. Don't do any allocations, including malloc, in your inner loop. Preallocate arrays for things like particles, or use free lists when you need large numbers of GC-managed objects (not good advice for Java anymore, but almost certainly useful in D). And so on.

In short, the less pressure you put on the GC, the less impactful its collections. The less often you allocate from the GC, the fewer collections it will run. So use it for the things you need it for, but be strategic about when you call the allocations.

This may help you get started:

https://dlang.org/blog/the-gc-series/

On Sunday, 1 August 2021 at 10:36:52 UTC, IGotD- wrote:

If it needs to. Not every allocation will trigger a collection. You can play around with something like appending items to an array in a loop and passing --DRT-gcopt=profile:1 to the program when you run it. This will spit out a report telling you how many collections were run, along with some timing statistics. There's an example here:

https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/

It's one of the tools available to make the best use of the GC.

On Sunday, 1 August 2021 at 10:36:52 UTC, IGotD- wrote:

the GC will only scan blocks that might have pointers in them. so let's say you have objects like

class Thing {
ubyte[] imageData;

this() {
imageData = new ubyte;
}
}

A GC scan of that is actually only like 64 bytes since it knows it doesn't need to look at the image data, only the class and the stack which can actually hold pointers.

On Sunday, 1 August 2021 at 08:54:05 UTC, Kirill wrote:

It entirely depends on the scope of the problem. For a script or tool, absolutely yes. Game development? Yes. Embedded? Maybe.

I implemented a voxel game (similar to Blockscape around 2012) and the GC was largely not a problem. The underlying array for a chunk of voxels (chunks come in and out of scope very frequently as the player moves), was malloced to reduce pressure on the GC (and to enable on-the-fly RLE compression). Otherwise, everything else was GC dependent and I did not have performance problems.

Some people complain about it, but I haven't had an issue. I think my usage of it was before they introduced the parallel-sweep GC. I don't recall GC pauses any longer than 4-5ms, and there was no stutter.

D's GC is significantly easier to manage than something like C#'s. I ported the game over from C# because I was always fighting .NET's GC. It always seemed to run, no matter how much I tried to stop allocations (while you can can temporarily stop the GC, it wasn't a solution). D's GC only runs when you allocate with new.

We might be able to give a more informed answer with some of your planned technical details. As is, I'd advise you use the GC.

D is in a very good position to become a gamedev language. The GC is very helpful, but when you really need, it's super easy to opt out. D is about giving you power.

On Sunday, 1 August 2021 at 08:54:05 UTC, Kirill wrote:

If D can provide more infrastructure for non-GC, I believe D will develop better and faster.