VML vsSqrt/vdSqrt Bad Results with dynamic linking with MKL version 10.2

VML vsSqrt/vdSqrt Bad Results with dynamic linking with MKL version 10.2

I have aa dlllibrary (myLibrary.dll) that links to the MKL libraries (libiomp5md.lib mkl_intel_c_dll.lib mkl_intel_thread_dll.lib mkl_cdft_core_dll.lib mkl_core_dll.lib). I am calling the vdSqrt() functions.We have been using MKL version 10.0.4.023 and everything worked fine.WhenIupgraded to MKL version 10.2.1.019,these functions are generating incorrect results for large vectors (larger than 4000 elements). When I changed my mylibrary.dll to a static library, vdSqrt() works fine for large vectors. I am using Visual Studio 2008.

There was an earlier thread on this forum, with a similar problem relating to an earlier version of MKL. The thread indicated that this was a bug fixed in later versions of MKL!

Any help is greatly appreciated.

15 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Quoting - nevineh
I have aa dlllibrary (myLibrary.dll) that links to the MKL libraries (libiomp5md.lib mkl_intel_c_dll.lib mkl_intel_thread_dll.lib mkl_cdft_core_dll.lib mkl_core_dll.lib). I am calling the vdSqrt() functions.We have been using MKL version 10.0.4.023 and everything worked fine.WhenIupgraded to MKL version 10.2.1.019,these functions are generating incorrect results for large vectors (larger than 4000 elements). When I changed my mylibrary.dll to a static library, vdSqrt() works fine for large vectors. I am using Visual Studio 2008.

There was an earlier thread on this forum, with a similar problem relating to an earlier version of MKL. The thread indicated that this was a bug fixed in later versions of MKL!

Any help is greatly appreciated.

Holtz,
thanks for letting us know. Can you get the test case?
--Gennady

Quoting - nevineh
I have aa dlllibrary (myLibrary.dll) that links to the MKL libraries (libiomp5md.lib mkl_intel_c_dll.lib mkl_intel_thread_dll.lib mkl_cdft_core_dll.lib mkl_core_dll.lib). I am calling the vdSqrt() functions.We have been using MKL version 10.0.4.023 and everything worked fine.WhenIupgraded to MKL version 10.2.1.019,these functions are generating incorrect results for large vectors (larger than 4000 elements). When I changed my mylibrary.dll to a static library, vdSqrt() works fine for large vectors. I am using Visual Studio 2008.

There was an earlier thread on this forum, with a similar problem relating to an earlier version of MKL. The thread indicated that this was a bug fixed in later versions of MKL!

Any help is greatly appreciated.

Attached is VS project to reproduce the problem. The Debug/Release configurations are for the problem dll case and the Static Debug/Static Release Configurations are for the working static linking case. Change the constant NUM_ELEMENTS defined in MKLTestApp.cpp to change the vector size.Setting the value to3389 or larger, will produce bad results in the dll case.
Thanks.

Attachments: 

AttachmentSize
Downloadapplication/zip MKLTest.zip9.12 MB

Quoting - nevineh

Attached is VS project to reproduce the problem. The Debug/Release configurations are for the problem dll case and the Static Debug/Static Release Configurations are for the working static linking case. Change the constant NUM_ELEMENTS defined in MKLTestApp.cpp to change the vector size.Setting the value to3389 or larger, will produce bad results in the dll case.
Thanks.

Some more info...

The problem happens when openMP support is turned on in the project. My guess is there is some conflict between openMP libraries in Visual Studio 2008and the ones used in MKL.

Also, if I pass the same pointer for the input andoutput (i.e, VdSqrt(n, a, a)) , I get incorrect output for large vectors. Is this a new restrictionin MKL 10.2? It used to work for earlier versions.

Nevine

Quoting - nevineh

The problem happens when openMP support is turned on in the project. My guess is there is some conflict between openMP libraries in Visual Studio 2008and the ones used in MKL.

You must assure that only a single copy of the Intel libiomp "compatibility" OpenMP library is linked, not the Microsoft vcomp library. libiomp will take care of any MSVC openmp parallelism consistently with MKL.

Quoting - tim18

You must assure that only a single copy of the Intel libiomp "compatibility" OpenMP library is linked, not the Microsoft vcomp library. libiomp will take care of any MSVC openmp parallelism consistently with MKL.

How can I configure my projectto use the the MKL libiomp libraries instead of Microsoft's?

Quoting - nevineh

How can I configure my projectto use the the MKL libiomp libraries instead of Microsoft's?

I believe you would put the libiomp which you want (dll version safest) in the additional library dependencies. If you don't have an Intel compiler, you would specify the one from you MKL library installation. If the link still tries to use the Microsoft vcomp, perhaps a nodefaultlib might be needed in additional command line options.
The link advisor on the forum page would indicate how the command line version of linking should go (possibly the static version).

Quoting - nevineh

Some more info...

The problem happens when openMP support is turned on in the project. My guess is there is some conflict between openMP libraries in Visual Studio 2008and the ones used in MKL.

Also, if I pass the same pointer for the input andoutput (i.e, VdSqrt(n, a, a)) , I get incorrect output for large vectors. Is this a new restrictionin MKL 10.2? It used to work for earlier versions.

Nevine

Nevine,
Thanks for test case. No, this is an unknown problem for 10.2 and there are no restriction for this functionality.
I didn't build and run your application yet, however the linking line you are using:

AdditionalDependencies="libiomp5md.lib mkl_intel_c_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib"

Is looks correct to me.
We need to check the problem on our side.
--Gennady

Nevine,
i used the test you proveided and I couldn't reproduce the result.

the output I got:

Success!
Press any key to continue . . .

#define NUM_ELEMENTS 33890

some more details aboutthe environment I tested:
CPU -- Intel Core2 Quad CPU @ 2.66GHz
MKL version -- Package ID: w_mkl_p_10.2.1.019
win32
VS2008

What is the CPU type you are working on?

--Gennady

Quoting - Gennady Fedorov (Intel)

Nevine,
i used the test you proveided and I couldn't reproduce the result.

the output I got:

Success!
Press any key to continue . . .

#define NUM_ELEMENTS 33890

some more details aboutthe environment I tested:
CPU -- Intel Core2 Quad CPU @ 2.66GHz
MKL version -- Package ID: w_mkl_p_10.2.1.019
win32
VS2008

What is the CPU type you are working on?

--Gennady

Gennady,

My enviroment is:
CPU: Intel Core2 Quad CPU Q6600 @2.40GHz
win32
VS2008
MKL 10.2.1.019

Nevine

Quoting - tim18
I believe you would put the libiomp which you want (dll version safest) in the additional library dependencies. If you don't have an Intel compiler, you would specify the one from you MKL library installation. If the link still tries to use the Microsoft vcomp, perhaps a nodefaultlib might be needed in additional command line options.
The link advisor on the forum page would indicate how the command line version of linking should go (possibly the static version).

Tim,

Thanks for the reply. I was successful in configuring the project and run it with the MKL libiomp5md instead of the Microsoft vcomp90 libraries only if I do not link to any other mkl libraries. When I link with the mkl libraries (mkl_intel_thread_dll.lib mkl_intel_c_dll.lib mkl_core_dll.lib), it tries tolink tothe Microsoft vcomp90 library.

I have added compiler option /D_OPENMP_NOFORCE_MANIFEST and used /nodefaultlib:vcomp90 as recommended in this article
http://software.intel.com/en-us/articles/how-to-use-intelr-compiler-open...

I can't get it to work with the MKL libraries.

Nevine

I've never tried -DOPENMP_NOFORCE_MANIFEST. Here's one of my screen echos when linking a release build, with debug symbols, with Microsoft /openmp built .obj with libiomp (note that any of these options which you specify are preceded by /link if you use a command line compiler to drive the link, as I do):
Microsoft Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

-out:mains.exe
-debug
-pdb:mains.pdb
-subsystem:console
-nodefaultlib:libiompprof5mt.lib
-nodefaultlib:libiompprof5md.lib
-defaultlib:libiomp5md.lib
-nodefaultlib:vcomp.lib
-nodefaultlib:vcompd.lib
mains.obj
...
so it appears that nodefaultlib requires vcomp.lib and vcompd.lib to be spelled out. In fact, there is no vcomp90 in my installation of VC9, so the spellings I quote are correct.

In case it's of interest, if you link with libiompprof5md, (as is recommended for thread profiler), but run normally without thread profiler, a file name guide.gvs is written each time you run, which contains statistics on OpenMP performance. All parallel regions in MSVC compiled code are lumped together, but the MKL parallel regions should be summarized separately.

Quoting - tim18
I've never tried -DOPENMP_NOFORCE_MANIFEST. Here's one of my screen echos when linking a release build, with debug symbols, with Microsoft /openmp built .obj with libiomp (note that any of these options which you specify are preceded by /link if you use a command line compiler to drive the link, as I do):
Microsoft Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

-out:mains.exe
-debug
-pdb:mains.pdb
-subsystem:console
-nodefaultlib:libiompprof5mt.lib
-nodefaultlib:libiompprof5md.lib
-defaultlib:libiomp5md.lib
-nodefaultlib:vcomp.lib
-nodefaultlib:vcompd.lib
mains.obj
...
so it appears that nodefaultlib requires vcomp.lib and vcompd.lib to be spelled out. In fact, there is no vcomp90 in my installation of VC9, so the spellings I quote are correct.

In case it's of interest, if you link with libiompprof5md, (as is recommended for thread profiler), but run normally without thread profiler, a file name guide.gvs is written each time you run, which contains statistics on OpenMP performance. All parallel regions in MSVC compiled code are lumped together, but the MKL parallel regions should be summarized separately.

Tim,

I was finally able to get it to work by adding /NODEFAULTLIB:"vcomp.lib" /NODEFAULTLIB:"vcompd.lib".

The vcomp90 is actually the dll name but the stub libraries are vcomp.lib and vcompd.lib.

Thanks for the help.

Nevine

I just started using vsSqrt and am noticing the same behaviors.  vsSqrt seems to be wrong in a similar manner as described in this post.  I am using the MKL v11 and Composer 13 with Visual Studio 2010.  Any explicit instruction on how to get the right version of OpenMP in place would be greatly appreciated.

>>... Any explicit instruction on how to get the right version of OpenMP in place would be greatly appreciated...

Please take a look at Intel Software Registration Center and all Redistributable Packages could be downloaded.

Leave a Comment

Please sign in to add a comment. Not a member? Join today