3 ms·

I have never seen a game developer argue for "no GC" in games, where "no GC" includes no arena allocators. anyone who advocates for this is misguided. it's much

I have never seen a game developer argue for "no GC" in games, where "no GC" includes no arena allocators. anyone who advocates for this is misguided. it's much better to use arena/pool allocators than to malloc/free dynamically, in games.

notacoward 3y ago
In my own domain of storage servers and such, I've had success using arenas - per request, usually, but also per session etc. For things with longer lives, object pooling has worked well. Very rarely have I needed much beyond those two, and I suspect the same might be true in games though I've never worked in that space. When I've had to work on codebases that did a lot more "random" allocations I've usually ended up having to spend time migrating toward one or more often both of those approaches just to keep the bug load down and myself sane. The really cool thing is that supporting custom allocators in a language and its libraries (e.g. Zig) makes both approaches easier, with less boilerplate. I see what's going on with the borrow checker in Rust and - as a long-time fan of static analysis - I understand that it might theoretically be better, but I find it hard to get very excited when I see that the implementation difficulty and cognitive load are so much higher than a simpler approach I've already seen work well.
- adamrezich 3y ago
  this is exactly how I feel! in school, the idea of pool/arena allocators wasn't touched upon at all—the options, as I was presented them, were either "manual memory management" (malloc/free/new/delete), "RAII" (smart pointers), or "garbage collection". I had not heard of the concept of "lifetimes", outside of scopes when using RAII, until later, and even then probably only after Rust made that be like it's whole thing. nobody ever told me, check it out, it's not hard to make like the dumbest possible "bump allocator", where you allocate a hunk of memory and dole it out bit by bit as the application requests it, and then later you can just free the whole hunk at once… or even just move the bump pointer back to the start, and reuse it next frame/request/etc.! that's like 95+% of the reason why people reach for things like garbage collection to begin with, and it seems so obvious in hindsight! actually, it was this top-shelf HN comment that really spelled it all out for me, and again, it all seems so obvious in hindsight: https://news.ycombinator.com/item?id=26443768&p=2#26451692 https://news.ycombinator.com/item?id=26443768&p=2#26451692
  - notacoward 3y ago
    Pretty awesome to see Andy Kelley, Steve Klabnik, and Joe Blow all writing at length about this stuff in one thread, isn't it? In a way, that was my original point. I didn't come here to say it's wrong for Cakelisp to forego tracing GC in favor of nothing at all, but just that the rationale - and maybe compatible solutions to common issues with that approach - should be explained better. I hope the author takes that to heart, because (as plenty of other comments here indicate) without explanation it's a blocker for many people.

notacoward 3y ago

In my own domain of storage servers and such, I've had success using arenas - per request, usually, but also per session etc. For things with longer lives, object pooling has worked well. Very rarely have I needed much beyond those two, and I suspect the same might be true in games though I've never worked in that space. When I've had to work on codebases that did a lot more "random" allocations I've usually ended up having to spend time migrating toward one or more often both of those approaches just to keep the bug load down and myself sane. The really cool thing is that supporting custom allocators in a language and its libraries (e.g. Zig) makes both approaches easier, with less boilerplate. I see what's going on with the borrow checker in Rust and - as a long-time fan of static analysis - I understand that it might theoretically be better, but I find it hard to get very excited when I see that the implementation difficulty and cognitive load are so much higher than a simpler approach I've already seen work well.

adamrezich 3y ago
this is exactly how I feel! in school, the idea of pool/arena allocators wasn't touched upon at all—the options, as I was presented them, were either "manual memory management" (malloc/free/new/delete), "RAII" (smart pointers), or "garbage collection". I had not heard of the concept of "lifetimes", outside of scopes when using RAII, until later, and even then probably only after Rust made that be like it's whole thing. nobody ever told me, check it out, it's not hard to make like the dumbest possible "bump allocator", where you allocate a hunk of memory and dole it out bit by bit as the application requests it, and then later you can just free the whole hunk at once… or even just move the bump pointer back to the start, and reuse it next frame/request/etc.! that's like 95+% of the reason why people reach for things like garbage collection to begin with, and it seems so obvious in hindsight! actually, it was this top-shelf HN comment that really spelled it all out for me, and again, it all seems so obvious in hindsight: https://news.ycombinator.com/item?id=26443768&p=2#26451692 https://news.ycombinator.com/item?id=26443768&p=2#26451692
- notacoward 3y ago
  Pretty awesome to see Andy Kelley, Steve Klabnik, and Joe Blow all writing at length about this stuff in one thread, isn't it? In a way, that was my original point. I didn't come here to say it's wrong for Cakelisp to forego tracing GC in favor of nothing at all, but just that the rationale - and maybe compatible solutions to common issues with that approach - should be explained better. I hope the author takes that to heart, because (as plenty of other comments here indicate) without explanation it's a blocker for many people.