we are using Intel MKL in a small but important subset of our code base, to solve various optimization problems and for general matrix/vector algebra.
Our code base is mainly c#, with a few c++ projects.
Up until now, we have used DllImport attribute directives to make the MKL functions accessible from within our c# code. This has worked while using MKL 8.X, while version 9.X and forward do not seem to support this "shortcut". Rather, a custom Dll must be built from the MKL library and object files.
This could be fine, and is fine for ia32, but we cannot make this work for the em64t platform, which is a big obstacle for us. (Actually, this holds only for custom built dlls linked against the MS VC runtime version 7.1. No later version of the MS VC runtimes has worked successfully using the custom dll approach). Currently, we are using MKL version 10.0.1.015.
To overcome this, I recently created a MS VS 2008 c++ project that produces a CLR assembly, with win32/x64 configurations, that provides a nice interface towards our c# code (i.e, has done away with the dllimports). And for the first time, computations have been succesful on both ia32 and em64t platforms. The assembly exposes classes with static methods for a small subset of LAPACK and BLAS1/2/3. This has been great for matrices of dimensions up to e.g. 12x12, but for a 16x16 matrix, I get an access violation using dgetrf().
I found a few other threads suggesting that the memory containing data and work arrays used with MKL should be allocated on the heap, rather than on the stack. I then used the windows HeapAlloc() function, allocating all input data and work arrays on the heap, with no luck.
Therefore, I seem to have identified a solution to the ia32/em64t problem, but at the same time imposed a rather useless limit on problem size.
Have anybody encountered similar issues using MKL with MS VS and c# on 32/64 bit platforms?
-- Thomas Allin