TBB allocators in Win32++

[uj]

I'm using a small GUI called Win32++.

http://users.bigpond.net.au/programming/

In my applicationwhen usingSTL template containers I always supply a TBB allocator.Win32++on the other hand usesthe default allocator throughout. Win32++ is based on include files only so it would be fairly easy I think to make it use some other allocator by the specification of a parameter.

Still, this would requireWin32++ to bemodified and before I suggest such a change I want to be sure it really matters. So my question is whetherit would be an advantage if Win32++ could use a TBB allocator when used with TBB applications? Would it matter?

[Alexey-Kukanov]

My guess is that the number of GUI objects allocated by Win32++ is probably rather small, so it would not matter much whether a faster allocator is used. However this intuition should better be supported by real observations, either with some benchmarks or with tool-based analysis. Comparative benchmarking however would require to do replace the standard allocator with the TBB one; possibly replacement of global new and delete operators could work. For tool analysis, one might runthe "standard" version of a benchmark under some profiling tool such as Intel VTune or Intel Performance Tuning Utility, and check whether the time spend in the allocator is any significant fraction of the total time.

[uj]

Thank you. Well, I think I've overdone it somewhat.

In my application I've replaced the8 new/deleteoperators globally as suggested on p. 105 in the TBB book. This should have the effect that whenever new/delete is usedin code that's statically linked to my program a TBB allocator is used.

I was under the impression that in addition to the aboveit wasnecessarytoexplicitly supply the TBB allocator witheach STL container I use. But this doesn't seem to be the case because the standard allocatorin fact uses the globalnew/delete. At least this is the impressionI get from reading p. 733 in The C++ Standard Library by Josuttis. It says,

"The default allocator uses the global operators new and delete to allocate and deallocate memory"

It should be sufficient to makethe global new/delete operators use a TBB allocator. Then all STL containers using the standard allocator willalso be using the same TBB allocator indirectly. So it shouldn't benecessarytoexplicitly specify a TBB allocator whenusingSTL containers, a TBB allocator will beused anyway.But maybe there's still some advantagein doing that?

[Alexey-Kukanov]

Yes, the C++ standard explicitly says that the default allocator (i.e. std::allocator) uses global new and delete operators. So if you override those globally, the containers will take the TBB allocator. I do not think that explicit specification of tbb::scalable_allocator for containers would provide any additional benefits, except for slightly less overhead because there would be no redirection through the global overrides; I'd assume that in real applications this additional overhead would be negligible.