- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am porting to windows a package that uses omp. I know very little to nothing on omp, so please bare w/me.
I want this to be in the same dll with mkl.
Can I nake sure that the omp thread management from mkl also covers the one I am building ?
If use the mkl omp to link is this sufficient ? I imagine that, if I use the visual studio 2010 omp, I will I have2 different omp's running in there. What if I build using the intel compiler ?
If not, is there a way to overwrite the omp calls of mkl (similar to overwritting the allocators ) ?
As I said I am in terra incognita here and counting my marbles.. ;-)
Thank you in advance for your help,
Petros
I am porting to windows a package that uses omp. I know very little to nothing on omp, so please bare w/me.
I want this to be in the same dll with mkl.
Can I nake sure that the omp thread management from mkl also covers the one I am building ?
If use the mkl omp to link is this sufficient ? I imagine that, if I use the visual studio 2010 omp, I will I have2 different omp's running in there. What if I build using the intel compiler ?
If not, is there a way to overwrite the omp calls of mkl (similar to overwritting the allocators ) ?
As I said I am in terra incognita here and counting my marbles.. ;-)
Thank you in advance for your help,
Petros
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you write OpenMP in Microsoft C++, the OpenMP library (libiomp5) used by MKL supports also the OpenMP function calls of MSVC++. If using CL to link, you will probably require
/link
-nodefaultlib:vcomp.lib
-nodefaultlib:vcompd.lib
to prevent linking the Microsoft OpenMP library, as well as linking the libiomp5 in accordance with the MKL link advisor. If linking with the Intel compiler, using /Qopenmp, the [no]defaultlib directives should be taken care of (you will see them in the build log).
As you suggested, you will have trouble if more than one OpenMP library is linked in.
If you call a threaded MKL function inside an OpenMP parallel, you create an OpenMP nested situation. By default, the OpenMP library in that case should not allow the MKL function to make additional threads. You have the opportunity to allow MKL to use additional threads by setting environment variable OMP_NESTED and setting MKL_NUM_THREADS or using the corresponding function call.
/link
-nodefaultlib:vcomp.lib
-nodefaultlib:vcompd.lib
to prevent linking the Microsoft OpenMP library, as well as linking the libiomp5 in accordance with the MKL link advisor. If linking with the Intel compiler, using /Qopenmp, the [no]defaultlib directives should be taken care of (you will see them in the build log).
As you suggested, you will have trouble if more than one OpenMP library is linked in.
If you call a threaded MKL function inside an OpenMP parallel, you create an OpenMP nested situation. By default, the OpenMP library in that case should not allow the MKL function to make additional threads. You have the opportunity to allow MKL to use additional threads by setting environment variable OMP_NESTED and setting MKL_NUM_THREADS or using the corresponding function call.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting TimP (Intel)
...If using CL to link, you will probably require
/link
-nodefaultlib:vcomp.lib
-nodefaultlib:vcompd.lib
to prevent linking the Microsoft OpenMP library...
...
As you suggested, you will have trouble if more than one OpenMP library is linked in.
...
/link
-nodefaultlib:vcomp.lib
-nodefaultlib:vcompd.lib
to prevent linking the Microsoft OpenMP library...
...
As you suggested, you will have trouble if more than one OpenMP library is linked in.
...
Hi Petros,
You could use aMicrosoft's Depends utilityto verify that'vcomp.dll'or 'vcompd.dll'are not going to
be loaded with your application.
Best regards,
Sergey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
TimP and Sergey,
Thank you very much for your responses.
All the best,
Petros
Thank you very much for your responses.
All the best,
Petros
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page