Managing memory with multiple heaps
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 10 of 10

Thread: Managing memory with multiple heaps

  1. #1
    Join Date
    Apr 2013
    Posts
    33

    Managing memory with multiple heaps

    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

  2. #2
    GCDEF is offline Elite Member Power Poster
    Join Date
    Nov 2003
    Posts
    11,980

    Re: Managing memory with multiple heaps

    I doubt that it's common, and it doesn't seem worth the effort to me.

  3. #3
    Join Date
    Apr 2013
    Posts
    33

    Re: Managing memory with multiple heaps

    Perhaps it's necessary when working on very big games for instance?

  4. #4
    GCDEF is offline Elite Member Power Poster
    Join Date
    Nov 2003
    Posts
    11,980

    Re: Managing memory with multiple heaps

    Don't know why they would be

  5. #5
    Join Date
    Dec 2012
    Location
    England
    Posts
    2,001

    Re: Managing memory with multiple heaps

    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.
    All advice is offered in good faith only. You are ultimately responsible for effects of your programs and the integrity of the machines they run on.

  6. #6
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,643

    Re: Managing memory with multiple heaps

    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.

  7. #7
    Join Date
    May 2009
    Posts
    2,413

    Re: Managing memory with multiple heaps

    Quote Originally Posted by royibernthal View Post
    Is it a common thing to do?
    I'd say it's bound to become very common since mutithreading is now part of the C++ standard.

    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.
    Last edited by nuzzle; April 16th, 2013 at 12:58 PM.

  8. #8
    Join Date
    Apr 2013
    Posts
    33

    Re: Managing memory with multiple heaps

    So you're saying I'll be using black boxed allocators anyway?

  9. #9
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,643

    Re: Managing memory with multiple heaps

    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.

  10. #10
    Join Date
    May 2009
    Posts
    2,413

    Re: Managing memory with multiple heaps

    Quote Originally Posted by royibernthal View Post
    So you're saying I'll be using black boxed allocators anyway?
    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.

    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
    Last edited by nuzzle; April 23rd, 2013 at 12:44 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Azure Activities Information Page

Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center