Intel® Moderncode for Parallel Architectures
Support for developing parallel programming applications on Intel® Architecture.

does intel C++ 11.1.038 support openmp3.0

ollehyas
Beginner
709 Views
Hifriends

visual studio 2008 and intel C++ 11.1.038 is combined to develope my parallel programme.
when the #pragma omp task is used, the runtime error "cannot find the 191 in libiomp5md.dll" appears.

I check the option in the project properties. the C/C++->language->openmp support display
"enable openmp2.0 lanuage extensions" . I wonder whereI can find the option "enable openmp3.0 lanuage extensions"
0 Kudos
6 Replies
TimP
Honored Contributor III
709 Views
omp task is enabled in the OpenMP option. You don't give enough information to judge the nature of your problem. In general, a number of bug fixes have come in current compilers. You could post a working sample of your problem on the C++ forum.
0 Kudos
ollehyas
Beginner
709 Views
Quoting tim18
omp task is enabled in the OpenMP option. You don't give enough information to judge the nature of your problem. In general, a number of bug fixes have come in current compilers. You could post a working sample of your problem on the C++ forum.

#include "stdafx.h"

#include

int fib(int n)

{

int i, j;

if (n<2)

return n;

else

{

#pragma omp task shared(i) firstprivate(n)

i=fib(n-1);

#pragma omp task shared(j) firstprivate(n)

j=fib(n-2);

#pragma omp taskwait

return i+j;

}

}

int main(int argc, char* argv[])

{

int n = 10;

omp_set_dynamic(0);

omp_set_num_threads(4);

#pragma omp parallel shared(n)

{

#pragma omp single

printf ("fib(%d) = %d\n", n, fib(n));

}

return 0;

}

0 Kudos
Michael_K_Intel2
Employee
709 Views
Hi,

I have some comments on your code:

the firstprivate(n) is not necessary. Variables that are private in the enclosing scope of a task constructs are automatically promoted to be firstprivate. In your case, n is a private variable (it is located on the function's call stack, which is private with respect to the parallel region). Hence, n is automatically private.

Other than that, your example looks OK to me. What's the problem with it?

Cheers
-michael
0 Kudos
Grant_H_Intel
Employee
709 Views
You should not need to enable OpenMP 2.0 extensions in the VS 2008.This switch is likely forVisual Studio, which does not include tasking support, so I would disable it. Instead, please make sure your code with OpenMP directives is being compiled by the Intel C/C++ compiler instead. I have forwardedthis threadto the appropriate Intel software development team for further investigation of the strange error message you received.

Best regards,
0 Kudos
Andrey_C_Intel1
Employee
709 Views
The note about OpenMP 2.0 support is about Microsoft compiler, looks like Intel's compiler just re-uses this phrase. Actually Intel Compiler 11.1.038 supports OpenMP 3.0, and this is proved by successful compilation of your test.

Runtime problem is unrelated to 11.1.038 compiler. Most probably you have some older compiler version which doesn't support OpenMP 3.0 in your path, like some 10.1 compiler. To fix the problem you need to launch Microsoft Visual Studio from environment set for Intel 11.1.038 compiler. E.g. run Intel Compiler 11.1.038 command line environment batch, and then run devenv.exe from this environment.

If you want some more details: when Intel compiler embeds itself into Microsoft Visual Studio it allows the IDE to use its environment during build phase of the project. But it does NOT allow using its environment during run phase. I don't know the reason of such behavior, but the reality is that in order to run OpenMP programs compiled by Intel compiler from inside the Microsoft Visual Studio IDE you need to set Intel compiler environment BEFORE launching the IDE. Thus you will allow using proper Intel compiler environment at application run phase.

Hope this helps.
Regards,
Andrey
0 Kudos
TimP
Honored Contributor III
709 Views
I suppose it's desirable to set appropriate NUM_THREADS and KMP_AFFINITY as well, before starting devenv. I run continually into unexpected delays of about 15 milliseconds when the scheduler decides to swap core assignments of a pair of threads, when I run from the VS.
0 Kudos
Reply