==A comparison Comparison from STL ==In general, most of STL is intended for use within a serial environment. This however changes with C++17's introduction of parallel algorithms.

==List <u>'''Memory Allocater'''</u>The use of TBB a memory allocator allows more precise control over how dynamic memory is created and used. It is the default memory allocation method(ie not the "new" keyword) for all STL containers==. The allocaters allow memory to scale rather then using delete and 'new' to manage a container's memory. They are defined within the header file "'''<memory>'''" and are coded as: <pre>#include <memory>

void foo(){std::allocater<type> name;}</pre> ==A Comparison from TBB=====Containers==='''<u>concurrent_queue</u>''' : This is the concurrent version of the STL container Queue. This container supports first-in-first-out data storage like its STL counterpart. Multiple threads may simultaneously push and pop elements from the queue. Queue does NOT support and front() or back() in concurrent operations(the front could change while accessing). Also supports iterations, but are slow and are only intended for debugdebugging a program. This is defined within the header "'''tbb/concurrent_queue.h'''" and is coded as: <pre>

'''<u>concurrent_vector</u>''' : This is a container class for vectors with concurrent(parallel) support. These vectors do not support insertion or erase operations but do support operations done by multiple threadssuch as push_back(). Note that when elements are inserted, they cannot be removed without calling the clear() member function on it, which removes every element in the array. The container when storing elements does not guarantee that elements will be stored in consecutive addresses in memory. This is defined within the header "'''tbb/concurrent_vector.h'''" and is coded as: <pre>

==List of TBB =Algorithms=== 

==Lock Convoying Problem=Allocaters====What Handles memory allocation for concurrent containers. In particular is a Lock?===used to help resolve issues that affect parallel programming. Called '''scalable_allocater<type>''' and '''cache_aligned_allocater<type>'''. Defined in "'''#include <tbb/scalable_allocator.h>'''"

A Lock(also called "mutex") ==TBB Memory Allocation & Fixing Issues from Parallel Programming==TBB provides memory allocation just like in STL via the '''std::allocater''' template class. Where TBB's allocater though improves, is a method through its expanded support for programmers to secure code that when executing common issues experienced in parallel can cause multiple threads to fight for a resource/container for some operationprogramming. When threads work in parallel to complete a task with containers, there is no indication when the thread reach the container These allocaters are called '''scalable_allocater<type>''' and '''cache_aligned_allocater<type>''' and ensure that issues like '''Scalability''' and need to perform an operation on it. This causes '''False Sharing''' performance problems when multiple threads are accessing the same place. When doing an insertion on a container with threads, we must ensure only 1 thread is capable of pushing to it or else threads may fight for control. By "Locking" the container, we ensure only 1 thread accesses at any given timereduced.

To use ===False Sharing===As you may have seen from the workshop "False Sharing" a lock, you program must be working major performance hit can occur in parallel(ex #include when data that sits on the same cache line in memory is used by two threads. When threads are attempting operations on the same cache line the threads will compete for access and will move the cache line around. The time taken to move the line is a significant amount of clock cycles which causes the performance problem. Through TBB, Intel created an allocated known as '''cache_aligned_allocater<threadtype>) and should be completing something in parallel'''. When used, any objects with memory allocation from it will never encounter false sharing. Note that if only 1 object is allocated by this allocater, false sharing may still occur. You For compatability's sake(so that programmers can simply use "find c++11 locks and replace"), the cache_aligned_allocater takes the same arguments as the STL allocater. If you wish to use the allocater with #include <mutex>STL containers, you only need to set the 2nd argument as the cache_allocater object.

Code The following is an example or Picture here ^_^provided by Intel to demonstrate this:

#include std::vector<iostreamint,cache_aligned_allocator<int>#include <thread> ;#include <mutex/pre>

//Some ===Scaling Issue===When working in parallel, several threads may be required to access shared memory which causes a performance slow down from forcing a single thread to allocate memory while other threads are spawned which call required to wait. Intel describes this function//Declared issue in parallel programming as '''Scalability''' and answers the following within issue with '''scalable_allocater<type>''' which permits concurrent memory allocation and is considered ideal for "''programs the class std::mutex NightsWatch;void GameOfThronesClass::GuardTheWall(){rapidly allocate and free memory''".

//Protect until Unlock() ==Lock Convoying Problem=====What is called. Only 1 thread may do this below at a time. It is //"locked"NightsWatch.Lock();?===

//IncrementDaysWithoutWhiteWalkerAttack++;std::cout << A Lock(also called "It has been mutex" << DaysWithoutWhiteWalkerAttack << " since ) is a method for programmers to secure code that when executing in parallel can cause multiple threads to fight for a resource/container for some operation. When threads work in parallel to complete a task with containers, there is no indication when the thread reach the container and need to perform an operation on it. This causes problems when multiple threads are accessing the last attack at Castle Black!\n"; //Allow Next same place. When doing an insertion on a container with threads, we must ensure only 1 thread is capable of pushing to execute it or else threads may fight for control. By "Locking" the above iterationNightsWatchcontainer, we ensure only 1 thread accesses at any given time.Unlock();

[[File:DarthVector ThreadLock.PNG |thumb|center|400px600px| Performance issues inside STL]]

Through '''concurrent_vector''', every time an element is accessed/changed, a return of the index location is given. TBB promises that any time an element is pushed, it will always be in the same location, no matter if the size of the vector changes in memory. With a standard vector, when the size of the vector changes, the data is copied over. If any threads are currently traversing this vector when the size changes, any iterators may no longer be valid.This support also goes further for containers so that multiple threads can iterate through the container while another thread may be growing the container. An interesting catch though is that anything iterating may iterate over objects that are being constructed, ensuring construction and access remain synchronized.  [[File:Gpuconcur.PNG |thumb|center|600px| concurrent_vector use with multiple threads]]

TBB also provides its own versions of the mutex such as '''spin_mutex'' for when mutual exclusion is still required.

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

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

*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

*As already stated most of === Identifying the STL containers are not thread safe. Though some operations in TBB containers are also not thread safe, like reserve() worries and clear() in concurrent_vector. responsibilities ===

*Thread Creation, terminating, and synchronizing, partitioning The increasing complexity of your code is managed by TBBa natural problem when working in parallel. This creates Knowing the responsibilities as in what you must worry about as a layer of safety on the programmer’s enddeveloper is key. When trying quickly implement parallel regions in your code, has they do not have or to deal with the threads themselves, making a developer less prone just to make mistakes in their keep your codeserial.

=== 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 , 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.

*Partitioning data.

====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