Reliable way to tell whether binary linked to MKL or FFTW

[William_Yessen]

Hello,

As I understand, Intel provides wrappers for FFTW. We have a large code base relying on FFT routines. Part of it uses FFTW, and part of it uses MKL. However, in both cases, we use FFTW interface. These "parts" are stand alone executables. I am curious - can we reliably determine whether an executable has been linked to FFTW or MKL (static linking)? I was thinking maybe something simple, like

nm mybin.a | grep -i 'some_unique_MKL_symbol' 

Thanks in advance for any help!

[Zhen_Z_Intel]

Dear customer,

There are several ways for check your function implementation uses FFTW for MKL. I recommend to use Intel Vtune analyzing module, function, threads and call stack to check, those functions uses MKL would be signed as [MKL xxx]@avx_function_name;

Best regards,
Fiona

[William_Yessen]

Thanks, Fiona. I am afraid this won't do it for us. We need a way to check without running any third party apps. For instance, some way to write a batch script to automatically check without human interaction.

[Arthur_A_Intel]

Hi William - One way that might work for you is to activate MKL verbose mode, i.e., export MKL_VERBOSE=1 in Linux system. This way you should see

MKL_VERBOSE DGEMM( ... ) ...

Now you can grep the output of your executable to check if the symbol was executed from MKL side. I hope this helps.

[William_Yessen]

Thank you, Arthur. This is closer to what we need. This would involve recompiling, of course, which isn't ideal, but it is functional. Thanks!

[Arthur_A_Intel · Accepted solution]

You don't need to recompile. If the executable was linked to MKL and you set MKL_VERBOSE=1 you should see the extra information from each MKL call. If linked with FFTW, setting this variable wouldn't display the verbose output.

[William_Yessen]

Hi Arthur,

Perfect, thanks! I got it now. For future reference, here's the link with more info regarding Arthur's suggestion: https://software.intel.com/en-us/articles/verbose-mode-supported-in-intel-mkl-112

[mecej4]

Another way, which will not make your EXE/DLL emit unexpected output, is to set the /MAP linker option when you build and examine the map file that is generated.

Yet another way is to run dumpbin /imports on the EXE.

These methods are more general because they do not require that the libraries/DLLs used have the capability of producing verbose output. Which method is better for you depends on who is going to deal with the diagnostic output that may be produced and whether you want the information to show only at build time or every time the application is run.