A bug in MKL library mkl_sequential.lib library?

[talmi__amos]

The static library "mkl_squential.lib" is not self sufficient.

When you link with it, it ( internaly) FORCE LINK with mkl_sequential.dll .

This is so, because a few routines - called inside the LIB - are contained only in the DLL. 

Think about it:  I linked with the static LIB, so I can distribute my software, because mkl_sequential.dll is not in the distribution pack. So, as far as staying legal, I am XXXed.  And this is just a visible tip of the iceberg:

You think you have only one set of internal variables? NO, you have two - those defined in the DLL and those defined in the LIB.  They have the same names, but routines in DLL use and call DLL::momo, not the LIB::momo.

If kuku is a library function that requires the DLL's yoyo functions, then:

The code (in kuku) prior to calling koyo is executed using the LIB variables and functions,  and the code AFTER yoyo  uses code and variables in the DLL. When YOU exiting kuku, and calls kukuA, which set do you see? the set of the LIB, not changed by yoyo or after-yoyo.

Such a yoyo function is "mkl_serv_print_verbose_info".  I have verified that this yoyo is actually called inside MKL versions of 2018, 2019, 2020.

There are at least  9 such yoyos ( I only used FFT 1-D routine):

mkl_dft_dfti_get_version_string,      mkl_dft_dfti_create_dc1d,    mkl_dft_dfti_create_dr1d, 

mkl_dft_bless_node_omp,                 mkl_serv_malloc,                     mkl_serv_free,

mkl_serv_verbose_mode,                  mkl_serv_dsecnd, mkl_serv_print_verbose_info,

mkl_serv_dsecnd

The Good stuff:

I have used MKL FFT.  I  have tried N exceeding 100,000 , of the shape 2*prime ( !! not 2^prime !!). I did expect an impossible long time. I did observe only a factor of 3 decrease. This should be impossible - unless someone discovered new FFT algorithms after I left school. Keep up the good work!

[mecej4]

I think that we need help from you to reproduce this behavior.

I took a short code that uses one of the functions that you named as problematic:

!
      program xdsec
      include 'mkl.fi'
      double precision ds
      ds=dsecnd()
      print*,ds
      end program

and built it using the command

ifort /MT /Qmkl xdsec.f90 mkl_intel_lp64.lib mkl_sequential.lib mkl_core.lib /link /map

I then opened a new command window that did not have the Intel Fortran compiler configured, and checked the DLL dependencies of the EXE that I just built:

S:\LANG\MKL>where mkl_sequential.dll
INFO: Could not find files for the given pattern(s).
S:\LANG\MKL>c:\cygwin\bin\ldd xdsec.exe
        ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffb8ed40000)
        KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffb8d000000)
        KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffb8c760000)
        imagehlp.dll => /cygdrive/c/WINDOWS/System32/imagehlp.dll (0x7ffb8d580000)
        ucrtbase.dll => /cygdrive/c/WINDOWS/System32/ucrtbase.dll (0x7ffb8bcc0000)
        RPCRT4.dll => /cygdrive/c/WINDOWS/System32/RPCRT4.dll (0x7ffb8d3b0000)

Note that there are no dependence on the Intel compiler or MKL DLLs.

If you build for multiple threads, or use third party libraries that depend on MKL, the situation could be different. That is why we need more details from you.

[talmi__amos]

dear mecej4,

My example is a bare-bone  version of Intel's basic_dp_real_dft_1d.c  example. It was compiled under "Intel compiler" using Visual Studio.  I included as "additional libraries" the "mkl_sequential.lib" 

My complete code is included.

After compilation and build, try running the EXE file ( not from the IDE, but from explorer 'run' command).  It will not run, complaining it must have 'mkl_sequential_dll' . 

Alternative: ask to create a MAP file. You will note that some functions (which I named 'yoyo') are taken from the mkl_sequential.DLL. 

Runing  LIB.EXE on mkl_sequential.lib proved that none of them is inside the library. Using Hex editor on this lib file,  you will find some of them are referenced by the lib file.

CODE:

#include <Windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <mkl.h>
#include <mkl_service.h>
#include <mkl_dfti.h>

typedef double double16 ;    // starts on a 16-byte boundary
typedef int ERC ;                      // 0 if OK, else an error
ERC FFT(double16 *X, int N);

// FFT demo problem
int main()
{
__declspec(align(16)) double xin[18];    // starts on a 16-byte

__int64 N = 16;
for ( int k = 0; k < N; k++)  xin[k] = 0;
xin[0] = 1;
FFT(xin, N) ;
return 0;
}

ERC FFT(double16 *X, int N)
// input: real N doubles
// output: ceil(N/2) complex units. half the FFT, packed format
// USES memory up to X[0:N+1] == N+2 doubles?  Exactly N for even N??.
// example copied from Intel

{
MKL_LONG status = 0;  /* Execution status */

DFTI_DESCRIPTOR_HANDLE hand = NULL;
char version[DFTI_VERSION_LENGTH] ;
DftiGetValue(0, DFTI_VERSION, version);

// FFT in-place
//printf("Create DFTI descriptor\n");
status = DftiCreateDescriptor(&hand, DFTI_DOUBLE, DFTI_REAL, 1, N ) ;
if (status != DFTI_NO_ERROR) goto failed ;

//printf("Set configuration: in-place\n");
status = DftiSetValue(hand, DFTI_PLACEMENT, DFTI_INPLACE);
if (status != DFTI_NO_ERROR) goto failed;

//printf("Commit the descriptor\n");
status = DftiCommitDescriptor(hand);
if (status != DFTI_NO_ERROR) goto failed;

//printf("Compute forward transform\n");
status = DftiComputeForward(hand, X);
if (status != DFTI_NO_ERROR) goto failed;

cleanup:
//printf("Free DFTI descriptor\n");
DftiFreeDescriptor(&hand);

//printf("TEST %s\n", (status == 0) ? "PASSED" : "FAILED");
return ((int)status);

failed:
printf("Intel MKL ERROR, status = %lld\n", status);
status = 1;
goto cleanup;
}

[talmi__amos]

Using the debugger, I found out that DftiGetValue() referenced  the "mkl_serv_print_verbose_info" function, and DftiCreateDescriptor() referenced "mkl_dft_dfti_create_dc1d".

I know for sure ( I rechecked now) that  "mkl_serv_print_verbose_info" ,  and " mkl_dft_dfti_create_dc1d" are NOT included in the library, but only in the mkl_sequential.dll .

Q.E.D.

[talmi__amos]

Some additional information:

System: Windows 10 64 bit,  using VS IDE from VS community 2017
Using Intel Math Kernel Library, sequential,  using ILP64 interface,

DftiCreateDescriptor() routine called
--> mkl_dft_dfti_create_descriptor_d1d
--> mkl_dft_dfti_create_descriptor_dc1d,  mkl_dft_dfti_create_descriptor_dr1d

The last two are not included in the mkl_sequential.lib .

The flags used  in compilation

/GS /W3 /Zc:wchar_t /ZI /Od /Fd"x64\Debug\vc141.pdb" /fp:precise /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Zc:forScope /RTC1 /MDd /Fa"x64\Debug\" /EHsc /nologo /Fo"x64\Debug\" /Qprof-dir "x64\Debug\" /Fp"x64\Debug\TestFFT.pch"

Linker options:
/OUT:"C:\Users\Amos\source\TestFFT\x64\Debug\TestFFT.exe" /MANIFEST /NXCOMPAT
/PDB:"C:\Users\Amos\source\TestFFT\x64\Debug\TestFFT.pdb" /DYNAMICBASE "mkl_sequential.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"  /DEBUG /MACHINE:X64 /INCREMENTAL /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Debug\TestFFT.exe.intermediate.manifest"  /MAP /NOLOGO /TLBID:1

[mecej4]

@talmi__amos :

Thanks for posting the source file. I have used it without change in the following.

You have used a large number of non-default compiler options, and it would take me some time to read the documentation and work through the reasons for using those options and the effects of each.

You talk of using ILP64, but you did not use -DMKL_ILP64 when compiling. However, this omission may have had no effect on the other issues. In obtaining the results that I report below, I used:

Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 2021.1.2.254 Beta Build 20200623

I compiled and linked twice, first using the command 

icl -I"%mklroot%"\include /MT /Od talmi.c mkl_intel_lp64.lib mkl_sequential.lib mkl_core.lib /link /map

and examined the map file. For the two entries that you mentioned, here is what I get:

 0001:000023e0       mkl_serv_print_verbose_info 00000001400033e0 f   mkl_sequential:mkl_print_verbose_omp_no_patched.obj
 0001:000037d0       mkl_dft_dfti_create_dc1d   00000001400047d0 f   mkl_core:_dfti_create_dc1d_fb.obj

The EXE is about 20 MB long, and has no dependence on any of the Parallel Studio or MKL DLLs. To confirm this, I opened a plain command window, and found:

Q:\lang\mkl>where mkl_sequential_dll.dll
INFO: Could not find files for the given pattern(s).

Running the EXE produced no complaints of not finding needed DLLs. The only DLLs that the EXE needs are NTDLL.DLL, KERNEL32.DLL and KERNELBASE.DLL .

I repeated these steps, specifying the additional compiler option -DMKL_ILP64 and the linker option to use mkl_intel_ilp64.lib . Again the results show no dependency on any DLLs other than the three Windows system DLLs that I mentioned. I did not use Visual Studio at all.

[talmi__amos]

Thank you mecej4 for pointing me .

I have observed the bug using Intel 64 Version 2019.4.245 running under MVS 2017 Comunity. 

mecrj4 have ran the same program using Intel 64 Version 2021.1.2.254 Beta, using ICI directly without MVS IDE, and observed no bug.

So, the problem is one of 3 - (1) My Error, (2) Software version, (3) MVS IDE "helpful defaults"

I have downloaded yesterday Intel System Studio 2020, the most recent version available to plebeians. I will remove any trace of the old compiler and run it under MVS, and report my observations.

[talmi__amos]

I have installed on a clean system, System Studio 2020, and ran it under Visual Studio. The following "Undocumented Features" are:

(1)  Project--> Properties -->  Configuration Properties --> Intel Performance Libraries-->Intel Math Kernel Library

         IF You answer     --> Use Intel MKL  sequential,  Use ILP64 interface YES, 

               Then the DLL mkl_sequential.DLL  will be loaded, full stop.  No way to override that. .

         IF You answer  Use Intel MKL  NO,  Use ILP64 interface NO, 

             Then  the mkl libraries you specify as additional inputs are actually used.

Specify them in Project--> Properties --> Linker --> Input --> Additional Dependencies.

(2)  There is no indication -  neither in the C/C++ command line, nor the Linker command line, that you chose static linking over dynamic ones. The linker command line may include the asked libraries, but that  is ignored  (if you asked for Intel Performance Libraries). The only way to control static linking over dynamic linking is through the "Intel Performance Libraries".

(3) The distribution kit of System Studio 2020 includes the MKL DLL files. Some previous versions of Intel Parallel Studio XE (those I used) behaved the same way,  but the distribution kit did not include MKL DLL files.

(4)  Granted,  this is logical. But why didn't Intel add a word of caution, to the tag Intel Performance Libraries, saying: "this will forces linking the dynamic libraries" ? Or, simply, change the tag to Intel Performance DLL libraries .

[Gennady_F_Intel]

to add such words of cautions is not a trivial task as Microsoft changed the IDE format w/o notifications.

Nevertheless, You may submit the Feature Request to the Intel Online Service Center to implement this option into one of the future versions of  Parallel and System Studios.