topic We think we know what is in Intel® oneAPI Math Kernel Library

Intel MKL WARNING: Library mkl_avx.dll (MKL type 7) is not suitable for this processor (MKL type 6).

Mark_Lewy — Wed, 02 Dec 2015 09:33:04 GMT

One of our clients is getting the warning in the subject, followed by the program failing, running our software. Any ideas what is causing this or how to resolve it?

The user is using a 32-bit version of Windows.

The processor is

Our software is built with “Intel(R) Parallel Studio XE 2015 Update 1 Composer Edition for Fortran Windows” .

Your processor image was not

Zhang_Z_Intel — Wed, 02 Dec 2015 18:24:12 GMT

Your processor image was not shown in your message.

My guess is the user somehow tried to invoke an AVX-based function on a non-AVX processor. Typically, MKL won't allow this to happen because it detects processor type at the runtime and automatically dispatch to an appropriate execution path. However, if the user did something funny to bypass this detection then they can shoot themselves in the foot. How do you link with MKL, the link line options, etc.? Which version of MKL is it?

Thanks.

The processor type should be

Mark_Lewy — Thu, 03 Dec 2015 09:14:06 GMT

The processor type should be visible in the image; it's a Core i7-2640M running at 2.8 GHz.

I'm assuming the user hasn't done anything silly with the installed program, as the executable, the Fortran and MKL DLLs are installed into the same folder using a Windows Installer package.

As I stated above, our software was built with Intel(R) Parallel Studio XE 2015 Update 1 Composer Edition for Fortran Windows, so I believe the version of MKL in use is 11.2.

We build and link our software with the VS2013 IDE: Libraries->Runtime Library is set to Multithread DLL (/libs:dll /threads), Libraries->Use Intel Math Kernel Library is set to Parallel (/Qmkl:parallel).

For the link line All Options are:

/OUT:"Release.Win32/sim.exe" /INCREMENTAL:NO /NOLOGO /NODEFAULTLIB:"vcomp.lib" /NODEFAULTLIB:"libcmt.lib" /DELAYLOAD:"hasp_windows_58779.dll" /DELAYLOAD:"iwntypes.dll" /MANIFEST /MANIFESTFILE:"Release.Win32\sim.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"Release.Win32/sim.pdb" /MAP:"Release.Win32/sim.map" /SUBSYSTEM:CONSOLE /STACK:8388608 /LARGEADDRESSAWARE /OPT:REF /OPT:ICF /FIXED:NO /IMPLIB:"D:\source\30000\engines\cs\sim_program\Release.Win32\sim.lib" ws2_32.lib libiomp5md.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib DelayImp.lib ..\..\..\allshared\licensing\keyreader\HaspHL\hasp_windows_58779.lib ..\..\..\libsrc\iwntypes\Release.Win32\iwntypes.lib delayimp.lib ..\sim\Release.Win32\sim.lib ..\simlib\Release.Win32\simlib.lib ..\simlib_lib\Release.Win32\simlib_lib.lib ..\ma48\Release.Win32\ma48.lib ..\tscal_lib\Release.Win32\tscal_lib.lib ..\..\infoworks_2d\iw2d_cuda_call\Release.Win32\iw2d_cuda_call.lib ..\..\infoworks_2d\iw2d_cuda_single_prec\Release.Win32\iwcudasp.lib ..\..\infoworks_2d\iw_2d_sim\lib1\Release.Win32\iw2d_sim.lib ..\..\..\allshared\licensing\keyreader\Release.Win32\keyreader.lib ..\iwsimstate\Release.Win32\iwsimstate.lib mkl_lapack95.lib

Additional Options are:

/MACHINE:I386 /fixed:no

Hope this helps.

We think we may have found

Mark_Lewy — Thu, 03 Dec 2015 10:40:01 GMT

We think we may have found the cause - our 32-bit installer was not installing mkl_avx2.dll.

Quote:MarkLewy wrote:

Zhang_Z_Intel — Thu, 03 Dec 2015 18:04:52 GMT

MarkLewy wrote:

We think we may have found the cause - our 32-bit installer was not installing mkl_avx2.dll.

The processor is a Sandy Bridge (http://ark.intel.com/products/53464/Intel-Core-i7-2640M-Processor-4M-Cache-up-to-3_50-GHz?q=%20i7-2640M). It does not have AVX2 instruction set. So why would mkl_avx2.dll matter?

We think we know what is

Mark_Lewy — Fri, 04 Dec 2015 09:08:47 GMT

We think we know what is happening now: our 32-bit installer is copying both mkl_avx.dll and mkl_avx2.dll to mkl_avx.dll on the destination machine. I assume that mkl_avx2.dll gets copied 2nd, in this case, replacing mkl_avx.dll, resulting in the error when the program tries to load the (wrong) DLL at run-time.

Thanks for your help.