TBB and nested parallelism with other thread libraries

TBB and nested parallelism with other thread libraries

Given a tbb flow graph of tasks, in which one graph node uses either boost threads or OpenMP to execute some operation in parallel, will the threads used in that node and the threads used by the tbb scheduler stomp on each other with context switches?

4 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

This can be an implimentation issue. Generally speaking TBB thread pool will be seperate from OpenMP thread pool and seperate from Boost threads. As such, oversubscription will (may) occure. You can start each thread pool with undersubscription.

*** Caution. TheOpenMP thread pool usually assumes the process main thread initiated the OpenMP thread pool .AND. is the root thread on all subsequent entries into OpenMP parallel regions.

Jim Dempsey

www.quickthreadprogramming.com

The cilk+ implementation is intended to cooperate with TBB in scheduling threads.
If working with OpenMP, not only is there no protection agains over-subscription, but the OpenMP affinity (KMP_AFFINITY for Intel OpenMP) would probably have to be left at default (none) as it will not track conflicts in core scheduling between TBB and OpenMP. You would depend on the OS scheduler to spread the work across available cores, but it would have no idea of any scheduling preferences from your application.

"If working with OpenMP, not only is there no protection agains
over-subscription, but the OpenMP affinity (KMP_AFFINITY for Intel
OpenMP) would probably have to be left at default (none) as it will not
track conflicts in core scheduling between TBB and OpenMP."
I would think that Intel OpenMP uses the RML to play nice with TBB?

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen