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

I use the GC. The GC is an extremely powerful tool for productivity. For a game your issue will be non-deterministic latency i.e. GC pauses. For this, I would recommend having a strategy for avoiding the GC - other people will write here and have written extensively before on how to do this, so I won't repeat all of those points and points to be. It may be worth a warning here: If you are going into a new field, you probably want to learn that field then try and do that field well rather than trying to learn how to make a good game engine and any game engine at the same time.

A small tip for any memory allocation: Before being clever and thinking about the internals of your memory allocator (which is important, to be clear), try to allocate less memory first - sounds simple but memory you never allocate has a cost of exactly zero.

Enjoy.

On Sunday, 1 August 2021 at 14:02:46 UTC, max haughton wrote:

Just to add, from my rough tests it shows that you can have unnoticeable collections for up to 300MB heap size depending on CPU/RAM specs, after that there is clearly perceivable stutter that drags FPS down esp. with loop allocations.

What this means in practice - it should be possible to go full OOP crap for game simulation using lightweight classes without any hiccups even with GC enabled, but all asset data should be handled differently and taken out of GC scannable heap to avoid long pauses.

But in reality one would probably choose another allocation strategy that will probably accounts for disabling GC until certain point later in time when collection pauses won't matter and do manual collect there (on pause menu, respawn, level change, etc...)

I only use GC for process that doesn't need to be realtime

For anything else (including my game engine) i don't use GC at all, instead i use allocators (malloc/free most of the time)

If you plan to make a game, try to avoid the GC as much as possible, it's not incremental, so whever it needs to do a collection, it'll pause all the threads, depending on the structure of the heap memory it can take multiple frames

But that's also a valid concern if you misuse malloc/free, so it's not an issue with the GC

But with games, you want to make sure you control the memory allocation strategy, and GC doesn't help with that

You can always GC.disable() and call GC.collect() during loading screens, but again, control your allocation strategy!

16ms per frame at 60FPS, anything above will introduce frame stutters

Even if it's one every minutes, user will notice, games need predictable performance, you don't want to miss a combo because your GC decided to collect this frame for up to 3 frames

GC is not an issue if you manually manage it GC.disable() then GC.collect() during loading screen

But if your game never has loading screens, or if they are spaced out for way too long, then it's preferable to manage everything without it at all

Pool entities, use arena allocators, GC only introduce issues that you have to workaround (threading for ex)

Generally GC is not an issue, until it becomes an issue

Use it with caution or manage things by yourself

The most important thing to do is to know exactly what you need, and when

Avoid heap allocation during hot loops at all cost, no matter if it's GC or malloc, they both slow

Remember frame budget is only 16ms per frame for 60FPS, stutters are not an option if you want a smooth user experience

And if people use 120HZ monitors, or 144HZ, then the frame budget becomes even lower

GC is faster at allocating memory, but collections induces pauses

As other said D is great at providing tools to avoid GC, so use that at your benefit

And as i said in other posts above, control your memory allocation strategy from the start, and things will be easier to manage

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

For Vibrant which is a very simple game (https://store.steampowered.com/app/712430/Vibrant/) I did get some GC pauses so the mitigation I used in the end was:

• memory pools
• deregistering audio thread, using core.atomic for game => audio communication
• minimize GC heap size. In particular, a GC void[] will be scanned but an ubyte[] won't IIRC.

All in all any time spent with GC optimization is well compensated by all the time the GC (and D) gives you in tooling, and non-realtime stuff.

Don't go with 100% manual memory management if you can avoid it! But you can go deterministic destruction with https://dlang.org/library/core/memory/gc.in_finalizer.html

On Monday, 2 August 2021 at 08:25:28 UTC, Guillaume Piolat wrote:

GC performance has been much improved since.
It would be great to have new guidelines about "how much GC heap will scan in <1ms" because at one point the research by Infognition said it was only 100kb.
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html

On Monday, 2 August 2021 at 08:27:51 UTC, Guillaume Piolat wrote:

The fork based GC is merged https://github.com/dlang/druntime/pull/3514 :)
It would be interesting to read an article about it.
Maybe it improves the use case discussed in this thread?

// Joakim

On Monday, 2 August 2021 at 08:49:36 UTC, Joakim Brännström wrote:

In gamedev context probably not, unless there is already some fork mechanism on Windows that i'm not aware of.

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

Here's a counterpoint article about D's GC being a nuisance in the context of game development:

https://www.benjamin-thaut.de/archives/20

be aware though the article is from 2012, so there may have been many improvements to the GC since that time.