FindMKL module: which mkl versions to prioritize

[jjwilke]

CMake can be set to compile/link with MKL flags for each of the follow versions:

• Intel10_32 (intel mkl v10 32 bit)
• Intel10_64lp (intel mkl v10+ 64 bit, threaded code, lp64 model)
• Intel10_64lp_seq (intel mkl v10+ 64 bit, sequential code, lp64 model)
• Intel10_64ilp (intel mkl v10+ 64 bit, threaded code, ilp64 model)
• Intel10_64ilp_seq (intel mkl v10+ 64 bit, sequential code, ilp64 model)
• Intel (obsolete versions of mkl 32 and 64 bit)

We need to choose an ordering in terms of preference.

[jjwilke]

I think the only difference is that ILPL is 64-bit integers and LPL is 32-bit integers? Which integers do we want to prefer and do we want to prefer threaded MKL?
I can make this configurable, but have to pick defaults.

@crtrott @srajama1 @kyungjoo-kim @ndellingwood
Is there someone more versed in MKL that can tell me how to do the defaults?

[kyungjoo-kim]

I would first check if the compiler is intel or not . If the compiler is intel, instead of giving compile/link flags, we can just give "-mkl". If the compiler is not intel and still we want to check mkl upon request, I would go for threaded version with 64bit int. MKL automatically turns off threading if the mkl call is made inside of opemp region.

[jjwilke]

Makefile.kokkos-kernels actually sets the include path and links to lp64 rather than using -mkl (AFAICT).

I can certainly just use the -mkl for Intel compilers, if that's how people want to do it and use whatever default the compiler gives us.

[kyungjoo-kim]

You can definitely follow the existing logic. I think that using "-mkl" whenever possible is the most portable way for intel compilers. I think that intel probably used to have many troubles in guiding users to use correct compile/link flags and developed the idea of using "-mkl" and it is a simple solution.

[ndellingwood]

@jjwilke does the FindMKL module in #491 account for what was discussed here?

[ndellingwood]

@jjwilke I think this can be closed and done as part of 3.0.00?

[jjwilke]

I believe so. The solution here was to only use MKL with Intel compiler. Can @kyungjoo-kim confirm: do we need MKL support for non-Intel?

[mhoemmen]

@jjwilke wrote:

do we need MKL support for non-Intel?

MKL supports use with GCC, and I've often used it that way. @rrdrake , does Sierra care about that use case?

[jjwilke]

Okay. Let's keep this open. I can have two configuration paths for Intel/non-Intel. If not Intel, I am going to look for MKL Intel10_64ilp only.

[rrdrake]

At this time, Sierra only uses MKL with the Intel compiler.

[jjwilke]

Okay, now I'm remembering the issues. Do we need 32-bit or 64-bit integers? I need to know whether to link LP64 or ILP64.

[mhoemmen]

@jjwilke Trilinos uses 32-bit integers (LP64) with BLAS libraries.

[jjwilke]

So this is fun. When using GCC, it is recommended to link libmkl_gnu_thread.so, but if you do that multi-threaded tests fails. If you build with GCC and libmkl_intel_thread.so everything works.