MKL 10.0.1 - PB : Sequential Version using both cores !

[yoann_fabre]

Hi,

I've got the following probleme : I want to use MKL in the multi-threaded application, so I need a thread-safe version of the library. As I understand such a version is provided by the "sequential" DLLs. But I also need my MKL calls to execute into only one thread : I've other applicative thread that must not be starved of CPU ressources at any time ! The probleme is : when linking with "sequential" I cannot disable multi-threading ! (not funny)

Machine(s) : Intel Core (1) Duo and Intel Core 2 Duo
OS(es) : WinXP-SP2 and Vista64 (but application is 32 bits only)
Compilo : MS Visual Studio 2005 SP1 (C++)
MKL : 10.0.1.015
LIBS from : C:Program FilesIntelMKL10.0.1.015ia32lib
LINKS with : mkl_c_dll.lib mkl_sequential_dll.lib (and ONLY that).
LINKS Nota : MSVC support of OpenMP is disabled and I do not link with it by hand.

SYMPTONS : no way to disable multi-threading ! ProcessExplorer shows that the application is using threads named "libguide40.dll!_kmp_launch_worker" and "libguide40.dll!_kmp_launch_monitor".

WHAT I've tried :
* call to mkl_domain_set_num_threads : all to 1
* call to mkl_set_num_threads(1)
* call to omp_set_num_threads(1)
* call mkl_set_dynamic(FALSE)
* call omp_set_dynamic(FALSE)
* checked and set the related env. variables

A query to [mkl_get_dynamic] ALWAYS return TRUE
A query to [omp_get_dynamic] return false as expected

When I execute a threadable computation (e.g. gemm) I get 100% CPU use : that is to say both cores are in full use ! I /need/ to rescrit MKL to one core and I /need/ a thread safe version (since another applicative thread may concurrently perform others MKL calls).

Questions :
* How can I do that ?
* What version/flavors of MKL are thread safe ? I find the doc quite unclear about this !

Important Final Remarque : If I link to [mkl_c_dll.lib mkl_intel_thread_dll.lib] then I CAN indeed disable the multi-threading with the above calls. That is to say [mkl_get_dynamic] return FALSE and computation use only 50% CPU (one thread/core). But, afaik, this version is NOT thread safe ! I mean : can two of my own threads performs concurrent calls (to say POTR) and all go well ?

NB : I also know the doc says to link with [mkl_ms_thread_dll.lib] instead of [mkl_intel_thread_dll.lib] since I'm using MSVC++ but I cannot find the former in my current installation ! Maybe I've got some install pb ? Or maybe the doc is outdated about that ? Also this may be related to the MKL Dll-Builder tool bug for IA32 that I've seem in another post. If you guys have built [mkl_sequential_dll.lib] with this tool then it should depends on [libguide] and then, maybe, it may "think" (using some internal state related to [libguide]) that it is allowed to use multithreading. But even so : why the hell does it prevent me to set [mkl_set_dynamic] to false ?

Thank for any help about this...

[TimP]

According to my understanding, when mkl_sequential library is linked, MKL is prevented from starting an additional worker thread, but an additional non-worker thread is possible. I suppose this is similar to the additional non-worker threads which are present when running OpenMP. I have never seen a case where the OpenMP library (e.g. libguide) is required by the sequential library. The additional thread should not "starve" you of any resources; if you can show that it does, please submit a reproducer problem report on your premier.intel.com account.
If you are not using the OpenMP library with mkl_sequential, I don't expect a KMP_AFFINITY setting to have any effect, so the Windows scheduler will not be inhibited from making the MKL worker thread hop around among cores.

[yoann_fabre]

Thanks for your reply...
But afaik you do not answer quite the question is was asking :-)

>> MKL is prevented from starting an additional worker thread,
Well, ... not ! As I said in my post I got 50% CPU in the application calling thread and another 50% CPU in a thread named [libguide40.dll!_kmp_laucnh_work] (according to ProcessExplorer)

>> I have never seen a case where the OpenMP library (e.g. libguide) is required
I've never said it was required ! Actually I do NOT use OpenMP and do NOT link against it. I only notice the /name/ of the above thread !

>> The additional thread should not "starve" you of any resources
I can assure you that when /both/ threads are running (doing gemm/potr in loop) the CPU load is 100% and the dual core is quite NOT responsive...

>> so scheduler will not be inhibited from making <...>
That's not my point !
How can I tell the sequential version to behave like the non-sequential one [mk_intel_thread.dll] that is to say to use only ONE thread. That was my question !

Please read again my orginal post, I gave lot of details. I'm quite not a noob here and even if it is still possible that I'm missing something obvious I do think the problem is strange. It seems to point toward either a bug in mkl_sequential or at the very least some probleme in the way it was generated. (please re-read the end of my post)

Also you do not say anything about the thread safety of [mk_intel_thread.dll] w.r.t non OpenMP thread. I notice that the doc is unclear about that too ! I "feel" there's might be a good reason for that...

PS : I do not have a [premier.intel.com account] but maybe the administrator who has installed my MKL have one. Anyway /I/ am supposed to do the job so I cannot really bug him right now with such a question (plus he's got /no/ clue of what I talk)

[TimP]

I didn't mention thread safety, as I wasn't sure what you were getting at. As I understand it, Microsoft support for non-thread-safe code goes away with VS2008 (and was never present in 64-bit mode), and all MKL libraries should be thread safe. The threaded MKL libraries automatically use additional worker threads (after checking against OMP_NUM_THREADS et al), while the sequential do not. It should be perfectly OK to call an MKL function from a threaded region. The threaded MKL could be called inside an OpenMP threaded region (with only one OpenMP library active). As I think you understand, the sequential MKL is likely to be used when calling in a threaded region, so that MKL doesn't start extra worker threads.

I can't follow your reports about whether you are using libguide intentionally or unintentionally.

Yes, one support account goes with an MKL license. If your admin didn't open the support account, perhaps she would be OK with your doing so. You should be able to see the serial number under which you are running.

[yoann_fabre]

Well... I'll try to make this crystal clear :

(a) I do NOT use openMP
(b) I do NOT want to use it
(c) I want to create an OS level thread A that call MKL function F with data D
(d) I want to create an OS level thread B that call MKL function F with data E
(e) I want F(D) executing ONLY inside it's calling thread A
(f) I want F(E) executing ONLY inside it's calling thread B
(g) I want the concurrent execution of F(D) and F(E) to be OK
(h) Point (g) means : Thread A running F(D) will NEVER blast some internal buffer that is ALSO used by thread B runnig F(E)

So my point is :

(1) I provably CANNOT do this with [mkl_sequential] : the call F(D) execute in thread A and in another worker thread. The call F(E) execute in thread B and in another worker. I provably CANNOT disable this behavior.

(2) I CAN do this with the threaded version setting DYNAMIC to FALSE and MAX_THREAD to ONE. BUT according to the doc the execution of F(D) and F(E) may interfere since A and B are OS level threads that have NOTHING to do with openMP (more precisely it is only what the doc entails. It's unclear)

(3) Thread safety has NOTHING to do with OpenMP or MS support of whatever. It is a question of absence of global states inside MKL, or if any, the use of standard OS level Mutex/Lock/Barrier to ensure say thread safety. See point (h)

(4) So we are back to square one :
(1) why the sequential version do NOT honor setting DYNAMIC to FALSE ?
(2) Is the OpenMP threaded version thread-safe w.r.t OS level threads ?

Feel free to comment ! Any help appreciated :-)
If some of my points are unclear please say so by letter or number !

[Todd_R_Intel]

Hello,

I think I might have an idea of what is going on. From your post I see that you are using mkl_c_dll.lib. This was once one of the interface libraries for MKL and is now present as a compatibility, or dummy library. The intent was to help customers make the transition in the naming of our libraries. It simply names some default libraries, one of which is mkl_intel_thread_dll.lib. That is of course not what youre looking for. Looks like there are quite a few documentation improvements we can make to avoid this misunderstanding and Ill follow up on that.

So my advice as a first step is to take a look in the user guide at the chapter on linking. I think the following is what you want:

mkl_intel_c_dll.lib mkl_sequential_dll.lib mkl_core_dll.lib

Don't forget to remove mkl_c_dll.lib. I think that will take care of (1) above.

Regarding (2) we maintain that all of MKL is thread safe. If there are problems with thread safety,there's a bug and you should report it at Intel premier support. When Im thinking thread safety by the way Im thinking of your points (g) and (h) above. I think the user guide needs to be improved in this area, so Ill report this as well.

There are some warnings in documentation about using our threaded version in certain threading environments but the intent is to help customers avoid situations where they would unintentionally cause more threads to be created than there are processing units or cores.

Hope that's helpful

[yoann_fabre]

MAD rosenqu :

Hi,
Thank you for your clear and helpfull reply !
You were right : my linking to mkl_c_dll.lib was the cause of the probleme. I can now get the expected behaviour. I've a few remarques :
(a) When I link to sequential [mkl_set_dynamic] has (still) no effect. [mkl_get_dynamic] always return [true]. This is not a problem since max_num_thread is 1 but it might be considered "strange" (IMHO : it should be forced to false and not to true).
(b) Since both versions of MKL (i.e. sequential and threaded) are thread-safe, then I do not understand anymore what is the purpose of the sequential one. I mean : it seems that I can get /exactly/ the behavior of [sequantial] while using [threaded] but forcing max_num_thread to one and dynamic to false ? isn't it ? May be I'm still missing something...
(c) About the doc (mainly the user guide) : why not make a "sticky" main thread about that ? kind of "suggestion for improving the doc"...
(d) IMHO : You should indeed clarify the thread safety issue. You make a lot of references to OpenMP but few to "more general" use case(s). It came from a good intention but I do think it is only clear for the HPC/fortran guys...
(e) As an exemple of the above point : you give quite a lot of linking line exemple... but there are all for fortran. Not a big issue (at least for me), but it's a damn give away of the whole spirit...
(f) NB : The doc talks about linking to [mkl_ms_thread_dll.lib] but this lib /does not exist/ in my installation : that's why I've "defaulted' to [mkl_c_dll.lib]...

well, thank again :-)

[TimP]

As to point (b), in the past, MKL did supply only a threaded version, and relied on an environment variable to prevent use of additional threads. Among other possibilities, MKL may be called from an OpenMP application, where the standard environment variables or omp_set_num_threads are required for use outside MKL; thus MKL needed its own environment variable. The sequential option avoids dependence on an OpenMP library and environment variable.