Hacker News Reader

Comment by sjmulder | Hacker News Reader

Cool. Also nice to see a well written ARCHITECTURE.md. I like this bit about dealing with memory:

> Almost all memory allocations in space-shooter.c are static, with dynamic allocations only used to load image and sound assets when the game initializes. This leads to a nice "programmer peace of mind" benefit that once the game initializes, I no longer have to worry about errors related to allocating or freeing memory.

It's something I also do myself in C projects - in fact in small programs I hardly ever find myself doing dynamic allocations at all. Functions that generate data don't allocate the memory themselves but receive a reference to an output location. That principle extends to larger programs. (It's not novel either, most system level libraries do this)

View on HN

Thanks! This was a revelation for me on a few levels:

1. That memory management doesn't have to be scary with a little forethought, at least for programs where you can set a reasonable upper bound on the resource requirements.

2. That it's possible to structure at least a subset of programs in such a way that error states can only be entered during initialization, and that makes the rest of the program much easier to reason about.

very cool project. i wonder if the libraries used in this project also offer the guarantee of static allocations only / dyn allocations only at startup. i’ve been using the JUCE toolkit for a project the past 10 years and it has allocations all over the place. need 16 bytes? malloc. need to concat that string? a few mallocs for handfuls of bytes. i am stuck with it, so i have had to override malloc and friends and build my own fixed block size allocator. very annoying to find out you are only doing static allocations but then all the libs you use together amount to 3000 malloc calls per second. i even found out that a call like glBufferSubData will call malloc or related functions. so doing that on each frame seems to be a bad idea as well.

> i even found out that a call like glBufferSubData will call malloc or related functions. so doing that on each frame seems to be a bad idea as well.

That's interesting and not what I'd expect at all! Is there documentation you could point me to or did you find that out with some tooling? And is there a better way to update attribute buffers for instanced draw calls?

I did not look up any documentation to verify this but since I did override all allocation functions I could keep statistics of how many calls I was getting for each function, and when I commented out the glBufferSubData calls I could see my stats drop. The contribution was somewhere around 300 calls/s I think... this is with the panfrost driver with gallium/mesa on an ARM platform. My plan is to use persistent buffers which are memory mapped once. Hopefully that will get rid of these allocation calls.

Thanks for the tip! I'll try to figure out if something similar is happening on either of the machines I'm using. That's a bummer that an in-place update function would be allocating behind the scenes...

I'm guessing the data is copied to a temporary buffer. The target GL buffer can still be in flight for previous operations. If I remember correctly, that safety can be disabled with the right incantation of flags on the buffer.

in that case you probably need a barrier? which is what you need with persistent mapping too?

This is one of the main advantages of using a lower level library like Vulkan or DX12. Higher level APIs like OpenGL and DX11 do a lot of work for you, but that work can result in extra allocations that you can't control, starting driver threads, extra resource transitions, etc

I practice something similar, I've statically allocated the physical RAM modules when I built my computer. O:)

Reply on news.ycombinator.com