==Business Point of View Comparison for STL and TBB==
{| class="wikitable collapsible collapsed" style="text-align: left;margin:0px;"
''I find your lack of grain disturbing''
===Which library is better depending the on the use case?===
One major aspect to look for when parallelizing a piece of code is the Cost- Benefit. Is it worth the time and effort to parallelize a part of your software only to get a small performance gain? Or is just faster to keep in serial? Many of these questions must be answered when deciding to parallelize your code or not.
TBB helps The real question is when should you parallelize your code, or to lower the cost of smaller performance benefit. Due to TBB requiring less effort to implement. Compared to other multi-threading librariesjust keep it serial?
*If are just trying TBB is for multi-threading and STL is for single threading workloads. The fastest known serial algorithm maybe difficult or impossible to parallelize a section of your code with a simple map, scan, or reduce pattern. Without much thought TBB has you covered.*When working with large collections of data TBB with its use of block range coupled with it algorithms makes it simpler to come up with solutions for the collection
TBB enables you Some aspects to specify logical parallelism instead of threads. It eliminates the time needed when developing a backbone look out for your code when working with threads. For quick and easy solutions for parallelize parallelizing your code TBB is the way to go.are;
STL stands on its own right*Overhead whether it maybe in communication, with its well-designed serial features. When trying to have more control near hardware levelidling, or you need to work near hardware levelload imbalance, the STL library with the threading libraries is the way to go. Though there are thread safety issues. synchronization, and excess computation
'''Conclusion''' *Efficiency which is the measure of processor utilization in a parallel program
TBB only gives you parallel solutions*Scalability the efficiency can be kept constant as the number of processing elements is increased, STL gives you provided that the foundations for many serial algorithms for sorting, searching, and a verity of containers.problem size is increased
*Correct Problem Size, when testing for efficiency, it may show poor efficiency if the problem size is too small. So, you would want to use serial instead, if the problem
size is always small. If you have a large problem size and has great efficiency, then parallel is the way to go
===Implementation Safety for TBB and STL ===
We are all human and we do make mistakes. Less mistakes done by developers will equal to less wasted time.
*TBB specifically makes concurrent_vector container not to support insert and erase operationsResource: http://ppomorsk. Only new items can be pushed back, and cannot be shrunksharcnet.ca/Lecture_2_d_performance.pdf
** This prevents developers to write bad code. If for example, we would allow insert and erase operations on concurrent_vector, it could cause a big performance hit. This performance hit can burden both iterating and growing operations which will not only make the concurrent containers in TBB unless, but also your program inefficient.
*As already stated most === Identifying the worries and responsibilities === The increasing complexity of your code is a natural problem when working in parallel. Knowing the STL containers are not thread saferesponsibilities as in what you must worry about as a developer is key. Though some operations When trying quickly implement parallel regions in TBB containers are also not thread safeyour code, like reserve() or to just to keep your code serial. ====STL and clear() in concurrent_vector. the Threading Libraries==== If you are going to try to parallelize your code using STL coupled with the threading libraries this is what you must worry:
*Thread Creation, terminating, and synchronizing, partitioning is managed , and management must be handled by TBByou. This creates a layer of safety on increases the work load and the programmer’s endcomplexity, has they do not have to deal with the threads themselves, making thread creation and overall resource for STL is managed by a developer less prone to make mistakes in their codecombination of libraries.
*Dividing collection of data is more of the problem when using the STL containers.
=== Identifying the worries and responsibilities ===The increasing complexity of your code is a natural problem when working in parallel. Knowing the responsibilities as in what you must worry about as a developer is key. When trying quickly implement parallel regions in your code, or to just to keep your code serial.====STL===='''If you are going to try to parallelize your code using STL coupled with the threading libraries this is what you must worry'''*Thread Creation, terminating, and synchronizing, partitioning, thread creation, and management must be handled by you. This increases the work load and the complexity. *The thread creation and overall resource for STL is managed by a combination of libraries.*Dividing collection of data is more of the problem when using the STL containers. Also mentioning that is not thread safe.*C++11 does not have any parallel algorithms. So, any common parallel patterns such as; map, scan, reduce, must be implemented by yourself, or by another library. But the latest STL Though C++17, will have some parallel algorithms like scan, map, and reduce.
The benefit of STL is due to the fact that you must manage the thread/ resources yourself which give you more control on the code, and fine tuning optimizations. Nonetheless, managing the thread yourself can be a double edge sword since with more control, it will take time implementing the code and the level of complexity will increase.
'''What you don’t need to worry about'''
*Making sorting, searching algorithms.
*Partitioning data.
*Array algorithms; like copying, assigning, and checking data
Note all algorithms is done in serial, and may not be thread safe
====TBBWorries and Responsibilities====*Thread Creation, terminating, and synchronizing, partitioning, thread creation, and management is managed by TBB. This make you need not to worry about the heavy constructs of threads which are close to the hardware level.
*Making a solution from close to hardware level allows Own Parallel algorithms (makes you need not to be flexible to worry about the solution you heavy constructs of threads that are wanting to make. But present in the major downside is the requirement lower levels of implementing the foundations first to make your solution workprogramming. It also simple map, scan, pipeline, or reduce TBB has the potential of making your program inefficient if not done correctly.you covered
TBB does have Parallel Algorithms support*Dividing collection of data, that has been already mentioned. the block range coupled with it algorithms makes it simpler to divide the data
'''Benefit'''
The downside of TBB is since much of the close to hard hardware management is done be hide the scenes, it makes you has a developer have less control on finetuning your program. Unlike how STL with the threading library allows you to do.
===Licensing===
TBB is dual-licensed as of September 2016
*COM license as part of suites products. Offers one year of technical support and products updates
*Apache v2.0 license for Open source code. Allows the user of the software the freedom to use the software for any purpose, to distribute it, to modify it, and to distribute modified versions of the software, under the terms of the license, without concern for royalties.
===Companies and Products that uses TBB===
*DreamWorks (DreamWorks Fur Shader)
*Blue Sky Studios (animation and simulation software)
*Pacific Northwest National Laboratory (Ultrasound products)
*More: https://software.intel.com/en-us/intel-tbb/reviews