concurrent vs. standard containers

[remi_chateauneu]

Is there a benchmark of TBB concurrent containers versus their standard counterparts ? For example tbb::concurrent_vector compared to std::vector, in purely sequential use ?

In other words, is it possible from now on,to use TBB concurrent containers everywhere, even when not needed ? This would give the possiblility to later add parallelism, without design changes.

If, on the other hand, these concurrent containers are significantly slower than the 'classic' standard ones, and if there is no way to locally disable synchronization, one may have to prioritize one execution mode over the other depending on where the bottlenecks are, this choice becoming maybe obsolete if other changes in his/her software move these performance bottlenecks elsewhere.

[Michael_V_Intel]

The concurrent containers are in general slower than their STL counterparts in sequential code, but of course enable cocurrency and scalability in parallel code.So unfortunately if you do replace your containers with TBB everywherein a sequential application, you will likelysee a slowdown. The performance impact will varyfrom application to application depending on the usage scenario though. So it's something you would need to evaluate for your application.

There is no way to "locally disable synchronization" in the TBB containers. In some cases to create thread safe and scalable implementations, the internals vastly differ between the standard containers and TBB's concurrent containers. It's therefore not as easy as skipping a synchronization here or there to get back to STLs sequential performance.