Discussion: Custom memory allocators for Tundra

[jonnenauha]

I know very little of custom allocators in practise. I'd like devs to take part in a discussion if we should use a custom memory allocator library in Tundra. I know for examle that Ogre uses something by default.

• Would custom allocator strategy vs. normal malloc/new be beficial in Tundra? Are we suffering from memory fragmentation etc.?
• What could the allocation strategy be?
• Should this strategy be used in all allocations or for example only for Scenes, Entities and Components that get iterated over lots of times? Afaik attributes are stack based, should they be moved to the heap?
• What kind of perf gains could be accomplised vs. time to develop and test this feature?
• What are the practical steps of implementing this. Just overriding new or is it more complex? I see that Ogre has OGRE_NEW that is used instead of new, is this due to they want to use the custom strategy only for certain things like scene nodes?

Please share resources and libs that we could use if you know good ones! I'll start with a few:

• http://people.cs.umass.edu/~emery/pubs/berger-oopsla2002.pdf
• http://www.canonware.com/jemalloc/
• http://www.nedprod.com/programs/portable/nedmalloc/

[jonnenauha]

Input from @juj and @cadaver would be nice as both of you have your own rendering engine projects and are experts in C++. You have maybe thought of the same thing in them?

[Stinkfist0]

I would suspect that there would not be significant advantages in Tundra until the majority of the lower level code (that Qt and esp. Ogre currently handle), where majority of the "crucial" allocations happen, would be in our hands. But I'm not any kind of expert in this area, so could be wrong.

[antont]

Not an expert either but seems that Stinkfist made an excellent point there.

Just for information: Blender has an own malloc too, guardedalloc or a safe malloc as it's sometimes called. Is handy because if you make errors in mem management it prints out warnings at exit when deving (yes that's why I know that much of it, it caught some errors I first made back then :)

is in http://www.gitorious.org/blenderprojects/blender/blobs/master/blender/intern/guardedalloc/MEM_guardedalloc.h

Written in and for c but there's a c++ version too, the doc seemed to say.

I figure works well for Blender as they don't use libs for GUI or rendering or such, the point Stinkfist made doesn't apply there much.

[cadaver]

Indeed, like Stinkfist said, the majority of low-level work (and thus also frequent allocations) are done in Qt and Ogre. Our largest memory allocations are mesh and texture resources + the work memory required by QScriptEngines. Comparatively our own Tundra code does (and allocates) very little.

Using multiple custom allocators in one process can even be harmful depending on their interactions; they may be allocating their own (large) memory pools, and would need careful investigation. In this regard adopting eg. Ogre's allocator for Tundra code would be safe, but would then increase coupling to Ogre.

I see custom memory allocation most beneficial when you have an in-house engine codebase with all of the code under your control and when you need explicit tracking of allocations, fragmentation etc. For example on consoles/mobiles where memory is severely limited.

Another possible benefit would be to unify the allocation behavior across platforms, as a custom allocator can optionally rely less on the operating system or the C runtime and do more of the allocation strategy & memory pooling itself. However if we talk about Windows for example, in the past the default allocator performance was notoriously poor but at least from Windows 7 onwards it has improved much, so custom allocators like nedmalloc will have less effect.

About one year ago I tested compiling Ogre with and without the custom allocator and it didn't have any noticeable effect on total memory consumption or application performance when loading large, asset-heavy Tundra scenes (on Windows.)