3 ms·

Game developers like me go through stages of grief in reinvention of memory management. In this case, what will eventually be reinvented is an arena allocator.

Game developers like me go through stages of grief in reinvention of memory management. In this case, what will eventually be reinvented is an arena allocator. Having just researched this, Cap'n'Proto is a good implementation of one that suits game development needs: (1) flexibility, (2) no serialization representation for networking and AI, (3) mutability of primitives, (4) garbage collection of stale objects in lists (i.e. removed items) is manual, (5) constraints to prevent non-performant design, and (6) support for these performance-sensitive idioms in multiple languages, not just C++. Migrating to an arena allocator is a completely different can of worms...

gpderetta 7y ago
Exactly. Also using a vector as underlying storage instead of sets of fixed size memory chunks seems not ideal to say the least.
- jokoon 7y ago
  I often read that when in doubt, use a vector. It has its disadvantages, but for performance it's usually okay. Simplicity can be a good choice.
  - exDM69 7y ago
    Sound advise for general purpose programming but not for (high end) games. Especially these days with multi-threaded game engines, a call to malloc() (e.g. from vector resizing) may attempt to grab a contended mutex and end up waiting until it misses its frame. Modern game engines use a combination of memory management techniques which are tuned for different use cases. For example: large, persistent blocks of memory are allocated ahead of time. Small, transient objects are allocated from a thread-local, per-frame pool and they're never freed explicitly (at the end of the frame, memory will be reclaimed for reuse). Most game engines don't use the C++ standard library containers at all in the first place. There are gamedev-flavored STL variants like EASTL, though.
    - jokoon 7y ago
      For triple-A game engines attuned to work on console hardware, sure, but they're really sophisticated optimizations. The STL is fine for a lot of things in gamedev. Object pools are not so hard to implement, the only thing a object pool really does is to reduce memory allocation and de-allocation delays while keeping the O(1) random access. It's just a strategy for allocating and accessing memory properly. It sounds like premature optimization, and it often is, because those strategies are not really trivial to use or implement.
- krona 7y ago
  Except that std::vector can be specialized with custom arena allocators, which isn't uncommon in performance sensitive applications.
  - gpderetta 7y ago
    std vector needs to be countiguous, so you cannot use a segmented storage.
    - krona 7y ago
      Most applications need more than one vector. Management of this with custom allocators pays dividends fairly quickly.
      - gpderetta 7y ago
        Sorry, there is some confusion here. The OP is literally implementing a custom allocator. I'm saying that using std::vector for the backing store of your allocator is wrong because resizing will invalidate your already allocated objects (which is a no-can-do in a general purpose allocator) and the copying is wasteful. A custom fixed size chunk based allocator woud be better.

gpderetta 7y ago

Exactly. Also using a vector as underlying storage instead of sets of fixed size memory chunks seems not ideal to say the least.

jokoon 7y ago
I often read that when in doubt, use a vector. It has its disadvantages, but for performance it's usually okay. Simplicity can be a good choice.
- exDM69 7y ago
  Sound advise for general purpose programming but not for (high end) games. Especially these days with multi-threaded game engines, a call to malloc() (e.g. from vector resizing) may attempt to grab a contended mutex and end up waiting until it misses its frame. Modern game engines use a combination of memory management techniques which are tuned for different use cases. For example: large, persistent blocks of memory are allocated ahead of time. Small, transient objects are allocated from a thread-local, per-frame pool and they're never freed explicitly (at the end of the frame, memory will be reclaimed for reuse). Most game engines don't use the C++ standard library containers at all in the first place. There are gamedev-flavored STL variants like EASTL, though.
  - jokoon 7y ago
    For triple-A game engines attuned to work on console hardware, sure, but they're really sophisticated optimizations. The STL is fine for a lot of things in gamedev. Object pools are not so hard to implement, the only thing a object pool really does is to reduce memory allocation and de-allocation delays while keeping the O(1) random access. It's just a strategy for allocating and accessing memory properly. It sounds like premature optimization, and it often is, because those strategies are not really trivial to use or implement.
krona 7y ago
Except that std::vector can be specialized with custom arena allocators, which isn't uncommon in performance sensitive applications.
- gpderetta 7y ago
  std vector needs to be countiguous, so you cannot use a segmented storage.
  - krona 7y ago
    Most applications need more than one vector. Management of this with custom allocators pays dividends fairly quickly.
    - gpderetta 7y ago
      Sorry, there is some confusion here. The OP is literally implementing a custom allocator. I'm saying that using std::vector for the backing store of your allocator is wrong because resizing will invalidate your already allocated objects (which is a no-can-do in a general purpose allocator) and the copying is wasteful. A custom fixed size chunk based allocator woud be better.