Linking against both the sequential and threaded mkl

[Mark_Thomas]

I have two dlls that link against the static mkl libraries.  One of the dlls links against the sequential version and the other against the multi-threaded version.  Those two dlls are then loaded in to the same process.  Does anybody know whether this is safe to do please?

Kind regards

Mark

[TimP]

This question would be more likely to get a useful answer on the MKL forum.

[SergeyKostrov]

>>...Does anybody know whether this is safe to do please?.. It has to be safe if processing of some data set is Not done at the same time by both DLLs.

[Mark_Thomas]

Thank you for your responses.  I've now opened this in the relevant forum - https://software.intel.com/en-us/forums/topic/531977.

[SergeyKostrov]

I'd like to add some clarifications... >>>>...Does anybody know whether this is safe to do please?.. >> >>It has to be safe if processing of some data set is Not done at the same time by both DLLs. Let's say your data set is very big, for example, 128 Mega Elements. Then, even if some processing is done by both DLLs at the same time, then everything will be safe if modules work on different non-overlapping partitions of the data set. PS: To be honest, I do not understand why threaded and non-threaded versions of MKL are used at the same time. It looks like some legacy issue in your project.

[jimdempseyatthecove]

>>To be honest, I do not understand why threaded and non-threaded versions of MKL are used at the same time. It looks like some legacy issue in your project.

There are perfectly good reasons to use both at the same time.

When an application has, at any point in time, large matrix(s) that can be processed by MKL and when there is no other threaded activity going on in the application, then you would want to use the multi-threaded version of MKL.

Conversely, when an application is multi-threaded and performing parallel activities in different sections of the code (iow not on same large matrix(s)), then the preferred route would be to have MKL use only the calling thread context as opposed to creating a new thread pool and oversubscribing.

You can also consider using mkl_set_dynamic(0) to inhibit nested parallelism, and/or use mkl_set_num_threads(n) with dynamic to control the degree of parallization (though I've read posts indicating issues with mkl_set_num_threads(n)).

Jim Dempsey