Our application MOSEK links with the static version of MKL and we have some issues in that regard.
Note that our apllication is .so or DLL that is linked with other applications by our users and those users may also use MKL. For instance our application is linked to MATLAB (www.mathworks.com) that also uses MKL..
1. The first issue is that you say mkl_free_buffers can always be called i.e.
In our exprience that is not the case if MKL is called form multiple threads because then the application may crash. Should we always be able to mkl_free_buffers unconditoinally?
2. In Linux 64bit using Intel C 13.0.0 our application runs fine if we do not call mkl_thread_free_buffers (we use that function instead mkl_free_buffers because that has issues mention under 1). However, if we do call mkl_thread_free_buffers it crashes. Should it not always work?
3. It seems if we call mkl_disable_fasst_mm that the problems goes away. However, if we do that then is only our static MKL library affacted? Or is the users application also affected e.g. MATLAB.
4. Do you have any information about how to dela with situation where an application may me linked with two diffrent version of MKL. One static and one dynamic for instance.
To us seems the buffer management is major pain to get information about and figuring out how it works. Can you shed any light on the issues we having.
We really prefer linking the sequential static version and not the DLL version. One reason is want to make sure we use the sequential version of MKL. If we use the DLL, then can we be 100% sure about that. Even if our library is linked into another application that uses MKL multithreaded. Also we we must not prevent the linking application from running multithreaded.
Regard mkl_free_buffers then this function generates a segmantation fault in some cases. It seems to happen if our applications runs two threads. Each thread uses MKL. Now one thread may finnish before the other and then call mkl_free_buffers and this seems to cause a crash.
If we do not use mkl_free_buffers everything run fine.
Btw if you link using a DLL then how much will
affect. Assume you have a program that is linked directly with MKL and a third party DLL that is linked with MKL. Nor assume the third party DLL calls
Will that also affect the MKL DLL linked directly into the program.
Let me reduce my questions to the following 2 questions.
1) What is effect of disable fast MM using
on average in your expirience? (Our exprience is performance is decreased negilible).
2) Assuming you have a DLL (or .so) that link MKL statically. If you call the function
then will this only affect the DLLs usage of MKL? Or does it also affect the calling applications usage of MKL? In other words what is the scope of globale variable you modify with this function. We think it should only in the DLL but is not sure.
Note our DLL export only limited set of symbols and all others are made private.
You confirm our observation. We have therefore just disabled the fast memory management. Since that makes our application crash occasionally. Without it things seems run perfect.
Btw. the error handling i.e. figuring out when MKL is running out memory is also very ugly. This is more likely when fast MM is turned oof. I do understand that is something you have inherited from the original BLAS/Fortran.
We define a customer xerblas function. In case of an error it modfies a global flag. Ocassionaly we check the global flag.
However, if you run multiple dgemms in parallel then if just ome fails you will have to see them all as errors. Each function should return its own error code.
I would very much like for each blas call know whther it was an success or failed. And the reason why. I also want this work in in multithreaded cases. I mean I call dgemm in multiple threads.
Background: Our application www.mosek.com solves optimizations problems e.g. linear programs. The engine requires we do a sparse Cholesky in every iteration. Now the parallelized sparse Cholesky employs sequential BLAS.
If we solve two LPs in parallel the sequential BLAS may be called from two different threads on inpdendent data. Although we have been informed that mkl_free_buffers can be called at any time then it sometimes make the application crash.
We have not tried to create a small example because we wanted to investogate if we have misunderstood something first. Now also disabling the buffer stuff seems to solve the issue.
I will work on test case when I have time. Since turning the buffer stuff off works very well it does not have a high priority right now. [I hope somebody else find the bug :-).] Thanks for your replies.