- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In my application I try to avoid dynamic allocation during run time. I allocate all objects in the initialization stageof my application. I know that TBBuses dynamic allocation during run time. Is there any way to avoidthis and to force allocationin thecreation stage of the application?
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"Is there any way to avoid this and to force allocation in the creation stage of the application?"
By reinventing TBB, perhaps?
Have you tried its scalable allocator (which lives up to its name), and, if you're not satisfied that it suits your purpose, what are you trying to achieve?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - eyalk
In my application I try to avoid dynamic allocation during run time. I allocate all objects in the initialization stageof my application. I know that TBBuses dynamic allocation during run time. Is there any way to avoidthis and to force allocationin thecreation stage of the application?
There are cases where dynamic allocations are prohibited. One example is the Joint Strike Airforce C++ coding standard which prohibits dynamic allocations,
http://www.research.att.com/~bs/JSF-AV-rules.pdf
But this is quite extreme. Few"normal" applications really benefit from this kind of rigidity,especially not if you're using a standard operating system like Windows, Linux, Mac OS X, Solaris, AIX or HP-UX.
So either your application is very extreme or you're avoiding dynamic allocations for more esoteric reasons: Like you've heard that dynamic allocations are slow and should be avoided. Or even that you feel dynamic allocations are hard to get right so you rather avoid them.
In any case it would be interesting to know why you're shying away from dynamic allocations. I can tell you right away that toaltogether avoid dynamic allocations on the standard OS:es I mentioned is close to impossible. What you could reasonably settle for is to not make any dynamic allocations yourself. And if you adopt thatthat approach you can use TBB without problems:)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - uj
There are cases where dynamic allocations are prohibited. One example is the Joint Strike Airforce C++ coding standard which prohibits dynamic allocations,
http://www.research.att.com/~bs/JSF-AV-rules.pdf
But this is quite extreme. Few"normal" applications really benefit from this kind of rigidity,especially not if you're using a standard operating system like Windows, Linux, Mac OS X, Solaris, AIX or HP-UX.
So either your application is very extreme or you're avoiding dynamic allocations for more esoteric reasons: Like you've heard that dynamic allocations are slow and should be avoided. Or even that you feel dynamic allocations are hard to get right so you rather avoid them.
In any case it would be interesting to know why you're shying away from dynamic allocations. I can tell you right away that toaltogether avoid dynamic allocations on the standard OS:es I mentioned is close to impossible. What you could reasonably settle for is to not make any dynamic allocations yourself. And if you adopt thatthat approach you can use TBB without problems:)
"Joint Strike Airforce C++ coding standard which prohibits dynamic allocations"
And it would also prohibit something like TBB, the military has a very narrow set of libraries they can use, TBB is probably not on it.
What I can imagine, and know, as normal is Games. A few years back (up until the previous generation of Game hardware XBOX,PS2,etc...) dynamic allocation was still considered, and rightly at the time, a boogieman. Even nowadays Game programmers try to avoid dynamic allocation if possible, normally using pool allocators nowadays, but in the past by allocating everything at the beginning of a level, and deallocating at the end, using no allocations in between was the norm.
When working on something like the Xbox360 or the PS3, TBB and it's allocators should be good enough. But if you were working on a Wii, or DS, PSP, or dare I say iPhone (game platform?), dynamic allocations could still be bad for a fast paced flashy action game (but a good pool allocator could still probably handle it perfectly well if you aren't too sloppy), the real point however is that these "weaker" consoles actually have very little to gain from incorporating TBB, the hardware itself isn't scalable, so using a scalable library like TBB won't actually scale, and instead just addunnecessaryoverhead.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page