error for R calling MKL with multithreading

[Bowen_M_]

Specifically, when using mkl functions (such as lapacke_dgesvd) in C++ with multi-threading, it works fine. But with the same function and R binding to call it under multi-threading, the result of SVD is not correct. Does anyone have an idea of what happened?

In addition, I used -lmkl_core -lmkl_intel_lp64 -lmkl_gnu_thread to compile, the C++ code compiled, but it won't work if I use -lmkl_rt. R binding compiles the other way, only with -lmkl_rt but not -lmkl_core -lmkl_intel_lp64 -lmkl_gnu_thread.

Thanks,

Bowen

[TimP]

Perhaps if you would give more detail, your question might be clearer.

I guess you are using g++ with OpenMP.   In that case, you must make consistent choices in the OpenMP support library.  Several choices:

1) mkl_sequential avoids MKL linking an OpenMP library.  This might be good if you call MKL from parallel regions.

2) mkl_gnu_thread should be compatible with libgomp (as implied by g++ -fopenmp)

3) Omit -fopenmp at the g++ link step and specify -liomp5.   libiomp5 supports all omp function calls from g++.  Then you can use the MKL default threading which depends on libiomp5.

[Bowen_M_]

Thanks for your reply. Let me specify the problem.

I'm testing lapacke_dgesvd (lapacke_dgesdd) for SVD computation. I can run it in C++ with multi-threading. With the same function, I can also make it a shared library (.so file) and calling it from R with dyn.load amd .C function. 

The problem I encountered is that in C++  the lapacke_dgesvd function with multi-threading performs correctly while with R binding lapacke_dgesvd produces wrong results with multi-threading.

When building the C++ functions, I was only able to build it with mkl dynamic parallel setting, i.e. with -lmkl_core -lmkl_intel_lp64 -lmkl_gnu_thread for linker. Meanwhile I was only able to build mkl sdl with -lmkl_rt for the R binding .so file. 

I have two questions:

1) How can I build C++ function and R bindings .so files with both mkl dynamic parallel setting and mkl sdl?

2) Why the current R binding produce incorrect result?

[TimP]

I'd still have to guess about your possible problems with static linking.  That requires the ld begin-group ... end-group specifications as quoted by the link advisor.  This assumes that all your references to MKL lie within the shared object you are building, and you will still require the libiomp5.so if you use that option (I don't know about static option for mkl gnu_thread).

If you didn't get a correct combination using a single OpenMP library, incorrect results could be a consequence.