How well is supported TBB in Visual Studio 2005

[jose-maria-gomez-ver]

At this time I have one licence of Visual Studio 2005 Team Edition, and I want to use TBB. I know that TBB is supported in Visual Studio 2005 but.. my question is.. Should I upgrade to VS2008 or VS2010 to take the most of TBB or TBB is fully supported with Visual Studio 2005. You know, it is 5 years old and perhaps the compiler is not fully supported.

Anyway, I will use Intel Compiler.. so.. i am not sure if upgrading worth it.

[jimdempseyatthecove · Accepted solution]

Since you have the Intel C++ compiler, with a good portion of the C++0x features, including Lambda function support, I believe you are in good shape for continuing to use VS 2005 (as I do here).

One advantage though of upgrading to VS2010 is the MSDN and VC documents will include Windows 7 API and samples. You will have to weigh this inconvenience against the cost for upgrade. A second advantage is the MS VC++ has additional parallel programming features (not part of TBB). If you want to experiment with those features against the parallel programming features of Intel products, youwill need a copy for that purpose. Use of TBB will not be advance though with the upgrade to VS2010 (other than foe Windows 7 support). Also, there are some (at least were some) integration issues with the ICC (and/or Intel Parallel Studio) with VS2010. These issues may have been worked out by now.

Keep in mind that the Intel developers of TBB, and many of the independent contributors to TBB, are using the compiler version you currently have.

Jim Dempsey

[jose-maria-gomez-ver]

Okey. So in my case I dont need vs2010. I am not really interested in the parallel extension of visual studio. What I want to use is some multiplatform libraries like TBB.

If you say that people that are developing TBB are using vs2005 a dont need much more time to think about.

thanks a lot.

[jimdempseyatthecove]

In addition to TBB you can always fall back onto OpenMP. And if your Intel C++ is current you may have Cilk++ too (You can see some discussions ofCilk++ on the forums here)
And if you want something different, check out QuickThread http://www.quickthreadprogramming.com
I will soon have a Linux version (Ubuntu x64 being tested now). For the moment it is available for Windows.

Jim Dempsey

[TimP]

In case someone reads too much into this, currently there is no plan for TBB or Cilk++ to work with OpenMP; they are pretty much mutually exclusive, unless the programmer takes responsibility for scheduling each on its own cores. Of course, the same applies for running independent multi-threaded tasks on the same platform with a single threading model. Cilk++, TBB, and Ct are intended to cooperate, but those rule out C or Fortran participating in threading.

[jimdempseyatthecove]

Thanks Tim, I guess I wasn't clear enough that this was an .OR. situation.

Running different thread models concurrently requires special care to avoid adverse interactions. The techniques you develop version X of the other threading model may not work with version X.1. So blending is a situation where you are on your own. If you encounter problems, there will be no support given by vendors supporting their products. The user communities may help.

If you must mix threading models the Jim Dempsey's "Rules for Fools" aka "Rules for Desperate Measures" would state something along this line:

1) Do you really need to mix threading models?
2) Are you really sure?
3) Really? Ok then...

Try to configure to undersubscribe each thread pool.

When the circumstances require that the number of threads in each thread pool sum to more than the total number of hardware threads on the system, then set you spin-locks, block-time (burn time) to 0 or the least value possible. This is to eliminate/reduce one thread pool's threads burning CPU time when they have no work to do while the other thread pool's threads have work to do. When the total threads from all pools is .LE. the available HW threads then this is not an issue (for these thread pools but it may be an issue to other things running on your system).

Keep the work seperated if at all possible.

The process main thread may have to start and initialize all thread pools. For some thread models this might not be a requirement. Some experimentaion would be required.


Example:

int main()
{
int ret = 0;
omp_set_nested(1);
#pragma omp parallel num_threads(2)reduction(|=:ret)
{
if(omp_get_thread_num() == 0)
{
ret |=mainTBB();
}
else
{
ret |= mainOMP();
}
}


The order of thread pool startup may matter (experiment).

*** repeat ***

Keep the work seperated if at all possible.

Example of conflicts:

barriers in one thread model must not be encountered by threads of a different model. Therefor, if you have a function that is used by different thread models and which must have a barrier then the different thread teams must use different barriers. This generally means you must write your own barrier technique.

Parallel constructs of one threading model can not be instantiated (e.g. parallel for) cannot be instantiated by threads of the different thread model with the potential exception that the process main thread might (might) be or function as a member of both threading models.

If you have any problems, contact Tim1 ;)
(just kidding)

In reality you are on your own, but some of us might offer suggestions (like get a different job).

Jim