nuzzle
July 7th, 2009, 08:24 PM
What to you think about Intel's TBB (Threading Building Blocks)?
Click to See Complete Forum and Search --> : Tbb?
JVene
July 8th, 2009, 04:24 PM
Threaded development has several very different goals, TBB seems to be focused on just one of them - parallel algorithms.
This is important enough to consider seriously when your work depends on parallel algorithms, but it is by no means a complete coverage. It appears that TBB may be superior to OpenMP in several areas, and from what I can tell (not having used TBB beyond a quick investigation) it uses a class library approach rather than an alteration 'under the hood' through the compiler. As such it seems to be more flexible and applicable to a wider range of problems.
TBB doesn't appear to address much in the area of offloading work from a main thread, typical of GUI design. In my own work about 60% or more of the need for threading involves responding to a GUI event by tossing the processing duty into a thread, leaving the GUI thread free to continue serving UI. TBB doesn't appear to have much to offer for this work, but that isn't a flaw. It simply suggests that TBB's specialization on parallel algorithmic work gives it considerable power in that domain, while other purposes for threading would be served by yet another library.
In a related requirement, another requirement is to devote threads to specific cyclic purposes, such as dividing the work in 3D games among AI, Physics and 3D engine execution. TBB has some features here, but much of that work is satisfied by the classes I use for the GUI type threading I mentioned above - essentially the ability to hand a thread a function object (functor, pointer to function, pointer to member function and object, etc) for execution. TBB isn't tuned for that, it's tuned for parallel loops and similar algorithms and related containment issues.
For the domain where TBB is aimed, it appears to be well thought out by version 2.x, with the potential for much faster response to user/customer requests (or complaints) than OpenMP can hope to provide.
This is important enough to consider seriously when your work depends on parallel algorithms, but it is by no means a complete coverage. It appears that TBB may be superior to OpenMP in several areas, and from what I can tell (not having used TBB beyond a quick investigation) it uses a class library approach rather than an alteration 'under the hood' through the compiler. As such it seems to be more flexible and applicable to a wider range of problems.
TBB doesn't appear to address much in the area of offloading work from a main thread, typical of GUI design. In my own work about 60% or more of the need for threading involves responding to a GUI event by tossing the processing duty into a thread, leaving the GUI thread free to continue serving UI. TBB doesn't appear to have much to offer for this work, but that isn't a flaw. It simply suggests that TBB's specialization on parallel algorithmic work gives it considerable power in that domain, while other purposes for threading would be served by yet another library.
In a related requirement, another requirement is to devote threads to specific cyclic purposes, such as dividing the work in 3D games among AI, Physics and 3D engine execution. TBB has some features here, but much of that work is satisfied by the classes I use for the GUI type threading I mentioned above - essentially the ability to hand a thread a function object (functor, pointer to function, pointer to member function and object, etc) for execution. TBB isn't tuned for that, it's tuned for parallel loops and similar algorithms and related containment issues.
For the domain where TBB is aimed, it appears to be well thought out by version 2.x, with the potential for much faster response to user/customer requests (or complaints) than OpenMP can hope to provide.
codeguru.com
Copyright Internet.com Inc., All Rights Reserved.
Copyright Internet.com Inc., All Rights Reserved.