Game and GC

[Danni Coy]

gc causes unpredictabilities in performance*. With games it tends to be
worst case performance that matters.

I would reccomend using std.experimental.allocator (even if you still use
the default GC backed allocator). This will allow you to swap out your
allocator for a more specialised one as your requirements become more
concrete.

auto foo = new CustomStruct();

becomes

auto foo = allocator.make!CustomStruct();

The next thing you probably want is @nogc - Last time I checked getting
IAllocator objects are a bit tricky to use in @nogc code. Currently I am
using https://github.com/radcapricorn/alloctraits to get around this
limitation (You will still need an allocator that doesn't use the GC, I use
Mallocator for test purposes).

* The GC itself is deterministic, but it is really easy to write code that
triggers GC pauses at times that is difficult track down.







On Sat, Apr 7, 2018 at 7:55 AM, Chris Katko via Digitalmars-d-learn <
digitalmars-d-learn at puremagic.com> wrote:

> I'm in the same boat. I do games. But I love D's syntax and template
> power. So I'm doing a full experiment.
>
> Honestly, if D is that big a liability, you'll encounter it long before
> it's "too late" to port it to C++.
>
> Last night I had stuttering issues, but I realized there was a single,
> C-function, being called too many times (and never deallocating!).
>
> But previously, I've also had stutter issues. Now granted, I test on a
> "crap" laptop 2 GB RAM / Celeron processor. But it'll be 60 FPS ... then
> spike down. If this happens again with my current project, what I'm going
> to do, is hack the open source garbage collector to fire off an
> event/console message EVERY TIME it actually pauses to collect. Because
> it's possible the GC isn't actually the problem, or, some simple change to
> a line of code may prevent the GC from being a problem.
>
> That said, there's also @nogc (but that's also a bit of a lie because they
> never tell you that ANY THREAD running GC code can pause ALL THREADS for a
> collection.)
>
> But if you're making games, you should really be using static pools
> anyway. What's the MAXIMUM number of objects/trees/maps your game will have
> at a time? It's simple (regardless of D, C, Python, or Lua). Static. Pools.
> Basically, you just allocate at startup a simple fixed-length array for all
> your objects. That way, you're never asking the OS for memory = Never
> needing the garbage collector. If you don't use all that memory? Who cares.
> RAM is cheap. And if your program CAN swell in size, that means your
> low-end PCs will fail without knowing why.
>
> So you just put all your objects in fixed length arrays of size
> MAX_OBJECTS, MAX_ENEMIES, MAX_ITEMS, etc. And deleting an object is as
> simple as erasing it, or marking it as "bool is_deleted = true;" and adding
> a new object is simply finding the first "is_deleted" and re-running the
> constructor / re-using the carcass of the dead object.
>
> 99% of AAA studios use static pools. Now technically, static pools are
> "chunks" of fixed length arrays. So you could have one pool for a "map",
> and start loading another pool for the next map you're going to enter, and
> then when you finally transfer to the next map, you then free the static
> pool by marking it as deleted. And repeat as necessary. So it's a very
> macro-level amount of allocations. We're talking like, less than a dozen
> actual entities. (Depends on gametype, of course. But the
> order-of-magnitude helps convey it.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20180407/97d422b1/attachment.html>