MKL compile/link options

[jaewonj]

Is there a way to check how / with which options the MKL libraries have been build?

[Gennady_F_Intel]

Quoting - jaewonj

Is there a way to check how / with which options the MKL libraries have been build?

Jaewonj, it's not clear how it will help you? There is no way to share this options ..
--Gennady

[jaewonj]

Quoting - Gennady Fedorov (Intel)

Jaewonj, it's not clear how it will help you? There is no way to share this options ..
--Gennady

Gennady,

You're right. Never mind please.


I have another question. When I profile my application that calls MKL , I see a lot of kmp* calls.

It kind of make sense what other openmp threading related calls do such as ___kmp_fork_barrier and __kmp_launch_thread, but I do not understand what kmp_print_version is for.

Thanks.

Jaewon

[Andrey_C_Intel1]

Quoting - jaewonj

I have another question. When I profile my application that calls MKL , I see a lot of kmp* calls.

It kind of make sense what other openmp threading related calls do such as ___kmp_fork_barrier and __kmp_launch_thread, but I do not understand what kmp_print_version is for.

Jaewon,

kmp_print_version is for printing of OpenMP runtime library version information during program execution. To force application to call this function you can set KMP_VERSION environment variable to 1.

Thanks,
Andrey

[jaewonj]

Quoting - Andrey Churbanov (Intel)

Jaewon,

kmp_print_version is for printing of OpenMP runtime library version information during program execution. To force application to call this function you can set KMP_VERSION environment variable to 1.

Thanks,
Andrey

Andrey,

__kmp_print_version is present and takes a substantial amount of time in a code profiles even though that KMP_VERSION is set to FALSE (which is the default)

What are possible the reason for that and is there any way to work around this.

Thanks.

[Andrey_C_Intel1]

Quoting - jaewonj

__kmp_print_version is present and takes a substantial amount of time in a code profiles even though that KMP_VERSION is set to FALSE (which is the default)

What are possible the reason for that and is there any way to work around this.

Jaewon,

The possible reason of the fact that you see __kmp_print_version takes significant time is the lack of debug information in the OpenMP library. Its internals are hidden from the profiler which tries to do its best to show you as much information as possible. But apparently the profiler mistakenly pointed you to the function which was not called actually. This often happenswhen you profile or debug binaries those don't containgebug information.

I don't think there is a wayto get correct source location information from optimized binaries compiled without debug information. This is true not only for Intel OpenMP library but for other binaries as well.

Thanks,
Andrey

[Case__William]

I have been using Lahey Fortran 32-bit compiler with an old version of the MKL. Recently I tried to upgrade to the 2019.5.281 version. I used the Intel® Math Kernel Library Link Line Advisor and saw that the only fortran compiler to select was Intel's. See attached jpg showing the selections I made. However, when I link with the suggested MKL libraries I get the 2 unresolved externals:

1)  security_check_cookie@4

2)  security_cookie

When exploring how to get around this I noticed that this can be due to the Intel compiler switch /Gs. Since I am using Lahey Fortran is there any option to resolve this issue? I don't see any switch in Lahey that accomplishes the same thing Otherwise I will have to continue using the older MKL version 10.2.4.032