Is it a common thing to do?
Does this tutorial seem legit or would you recommend a different one?
http://publib.boulder.ibm.com/infoce...2Fcumemmng.htm
Printable View
Is it a common thing to do?
Does this tutorial seem legit or would you recommend a different one?
http://publib.boulder.ibm.com/infoce...2Fcumemmng.htm
I doubt that it's common, and it doesn't seem worth the effort to me.
Perhaps it's necessary when working on very big games for instance?
Don't know why they would be
What the article says is true. However, as GCDEF said in post #2, in most cases it's really not worth the extra effort. It's sometimes helpful though in a heavily multi-threaded application to have a separate heap for certain threads that make heavy useage of new/delete local to the thread.
As 2kaud mentioned. in multithreaded apps it can be a way to increase performance by not having each thread contend for the same heap. Note that this does mean that memory you allocate in one thread gets disposed of in that same thread, or you may not be getting the expected performance increase.
This may be part of a custom allocator for some class. Although more often than not custom allocators have more to them than just a different system heap.
if you know a particular class will only allocate memory of specific sizes you may use this in a way to avoid excessive heap fragmentation. Although again, a custom allocator will probably be a better fit.
I'd say it's bound to become very common since mutithreading is now part of the C++ standard.Quote:
Originally Posted by royibernthal
But this doesn't mean programmers suddenly will start tinkering with multiple heaps in applications. It simply means standard allocators will evolve to efficiently run programs written according to C++ 11. I don't think custom allocators and programmer optimization efforts can do much better. And there are many potential dangers especially regarding portability.
So you're saying I'll be using black boxed allocators anyway?
no, if you don't specify an allocator, you'll get the single default one.
if you need multiple system heaps, you'll need to explicitely declare/define your containers to need an alternative allocator. This isn't any diferent than it is today.
If you're referring to my reply, what I mean is that since C++ 11 supports multithreading the default heap allocator (the one you get if you don't actively replace it) has to be able to efficiently handle this situation. And this most likely means it uses multiple heaps. No compiler manufacturer can risk loosing face by allowing their baby to cause show stopping pauses during runtime. In my view this removes at least one of the major reasons for programmers to manage their own system heaps.Quote:
Originally Posted by royibernthal
One really should think twice before taking on chores that naturally belong to the compiler and the runtime system. It usually ends in disaster; More strange, subtle and hard to find bugs, and slower, messier, less portable code to boot.
If you want to try a different heap allocator that's fine but use general plug-and-play replacements only. If your program doesn't get any faster or there are problems, no big deal, it's just to put the default allocator back again. There are several available, most notably maybe the one from Intel which is part of the TBB multitasking package. It's free and quite portable. I tried it but to my big surprise it wasn't any faster in my application than the default allocator from Microsoft. This only enforced my belief that default heap allocators today are very good and not the tar pits they used to be.
You meantioned big games but the trend there actually is away from highly optimized C++/C code, at least outside the game engine. Instead scripting languages such as Lua, where the emphasis is on simplicity rather than speed, are gaining for the game logic.
http://threadingbuildingblocks.org/
http://www.lua.org/about.html