Custom Memory Allocation
Author
Hi Guys.
I was wondering if you could share some of your ideas on memory allocation in games. Specifically, I was thinking about using the Doug Lea Malloc. For my memory allocations, I have the following requirements:
1) Zero to no memory fragmentation. I am working on embedded devices.
2) Fast allocations and deallocations.
3) Moving memory allocations from the kernel space to the user space on embedded devices.
4) Minimizing memory consumption, although the other points are by far more important than this one.
Previously, I have been using pools of various sizes for memory allocation. I am, however, also looking at other ideas and came across Doug Lea malloc, which would be a little more flexible. I am also willing to combine several approaches and use them individually, when appropriate.
What other ideas are out there?
Thanks!
Florian
In some (last gen) console games that I've seen, they just allocate a whole chunk of memory for a level to use. An index into the next unused byte is maintained, allocations just increment this index. There is no deallocation until the end of the level, where the index is set back to 0.
Obviously no allocations take place at all during gameplay, it's all done during the loading phase.
I've heard this strategy called a "mark and release heap".
Obviously no allocations take place at all during gameplay, it's all done during the loading phase.
I've heard this strategy called a "mark and release heap".
Author
Thank you, Hodgman, for sharing your idea. I have read about this approach and while it certainly deserves its existance (fast and efficient, no fragmentation, dynamic allocation sizes, etc). It does come with a couple of drawbacks, specifically being comparatively hard to use (not very forgiving if you make an error) and not allowing for deallocation, hence memory might go wasted if it is used only once, but never thereafter. Depending on whether one can live with these drawbacks, its certainly an approach to consider.
In my case, I want to be able to pseudo-allocate and deallocate memory at any time during the game (think dynamically spawning particles, for example), even on a per frame basis. Of course, I will not be actually allocating the memory, but just retrieving a pointer to whatever memory chunk is currently free. The actual allocation however, would happen at startup or level-load.
Are there any other approaches out there, that might be worth considering?
In my case, I want to be able to pseudo-allocate and deallocate memory at any time during the game (think dynamically spawning particles, for example), even on a per frame basis. Of course, I will not be actually allocating the memory, but just retrieving a pointer to whatever memory chunk is currently free. The actual allocation however, would happen at startup or level-load.
Are there any other approaches out there, that might be worth considering?
1) The mark-release heap is very useful. Expecially for single-frame buffers you might need, since you can drop the whole allocation at the end of the frame. You can always add new "marks" allowing you to use it for temporary allocations within some scope, and dropping it back to a previous point.
2) Memory pools are common. Allocating a segment of memory, and using it to quickly return allocations and frees of many small items. (like your game entities).
3) Block allocators. Allocate memory only in fixed sized blocks (ie one cache worth of data). Anything can use it however it wants, but the blocks only come in one size. Useful for things like file/network buffers. Useful as a layer ontop of memory pools, where each pool would grab "blocks" to allocate from (good for particles). Usually done in with a simple linked list of "free" blocks.
4) Custom heaps. Sometimes it isn't that "new"s "heap" algorithm is bad, but choice algorithm doesn't fit your needs. Maybe first fit, best fit, or worst fit, will give you better performance.
5) Consider allocators that take in fixed blocks of memory to use. That way you can make the same allocator rutine work on both a global scale, and on small stack allocated buffers. You can also use this to make sure each thread gets its own allocator pool, instead of having to lock a global allocator.
6) Consider that memory alignment can be beneficial. It increases performance in the general case, but is needed for some specific optimizations like using SSE instructions effectively.
7) YES! Do choose the right allocator for the job. Pool allocators might be good for game objects or particles, but won't work for allocating temporary buffers for loading/decompressing files and sounds. Likewise, using a heap for your particles is a bad idea, but heaps still work wonders in the general allocation case.
2) Memory pools are common. Allocating a segment of memory, and using it to quickly return allocations and frees of many small items. (like your game entities).
3) Block allocators. Allocate memory only in fixed sized blocks (ie one cache worth of data). Anything can use it however it wants, but the blocks only come in one size. Useful for things like file/network buffers. Useful as a layer ontop of memory pools, where each pool would grab "blocks" to allocate from (good for particles). Usually done in with a simple linked list of "free" blocks.
4) Custom heaps. Sometimes it isn't that "new"s "heap" algorithm is bad, but choice algorithm doesn't fit your needs. Maybe first fit, best fit, or worst fit, will give you better performance.
5) Consider allocators that take in fixed blocks of memory to use. That way you can make the same allocator rutine work on both a global scale, and on small stack allocated buffers. You can also use this to make sure each thread gets its own allocator pool, instead of having to lock a global allocator.
6) Consider that memory alignment can be beneficial. It increases performance in the general case, but is needed for some specific optimizations like using SSE instructions effectively.
7) YES! Do choose the right allocator for the job. Pool allocators might be good for game objects or particles, but won't work for allocating temporary buffers for loading/decompressing files and sounds. Likewise, using a heap for your particles is a bad idea, but heaps still work wonders in the general allocation case.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement