Access Violation using dgetrf (MS VS2008) on not so large matrices

[thomasallin_dk]

Hi,

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

[Gennady_F_Intel]

Hello Thomas,
It is possible for you toprovide a small test case to show the problem?
As I recalled, the custom DLL issue (depend on MSVC 7.1), which should be resolved since MKL 10.2 (the latest version is MKL 10.2.2.025).
You maydownload the latest MKL version from Register Center https://registrationcenter.intel.com/regcenter/register.aspx
and let us know if it works on yourcurrent methodor by custom DLL.

Regards,
Ying H.

[thomasallin_dk]

Hi,

thank you for the update hint. I downloaded and installed as an evaluation version -- everything seems to work now; I don't know what caused the limit on problem size, but this is a non-issue now. The dependency on MS VCR 7.1 is gone, as you mentioned. Nice.

I guess we will need to renew our license then - can this be done as a renewal or must we re-buy the product?

Best regards,

Thomas

[TimP]

Quoting - thomasallin.dk

thank you for the update hint. I downloaded and installed as an evaluation version -- everything seems to work now; I don't know what caused the limit on problem size, but this is a non-issue now. The dependency on MS VCR 7.1 is gone, as you mentioned. Nice.

I guess we will need to renew our license then - can this be done as a renewal or must we re-buy the product?

Renewals are available, but they extend the license only for a year from previous expiration.
MKL is included in current C++ and Fortran compiler products.

[Gennady_F_Intel]

Quoting - tim18

Renewals are available, but they extend the license only for a year from previous expiration.
MKL is included in current C++ and Fortran compiler products.

Thomas,
as an additionally with tim's words,
here are some disscutions about licensing:http://software.intel.com/en-us/articles/download-registration-licensing/
--Gennady

[Vladimir_Koldakov__I]

Hi Thomas,

Have you resolved the issue? I do not see a problem to call dgetrf from C#.

Below is my test, it passes on ia32 and Intel64 architecture. Commands for the last arch:

$ set lib=%MKLROOT%em64tlib;%lib%

$ link /DLL /MACHINE:AMD64 /def:user.def mkl_intel_lp64_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib user32.lib /out:mkl.dll

$ set path=C:work;%MKLROOT%em64tbin;%path%

$ csc .dgetrf.cs

$ dgetrf.exe

File user.def consists of two lines:

EXPORTS

dgetrf

// File dgetrf.cs

using System;

using System.Security;

using System.Runtime.InteropServices;

using mkl;

public class dgetrf

{

private dgetrf() {}

public static void Main(String[] args)

{

int n = 16;

int info;

double[] a = new double[256];

int[] ipiv = new int[16];

for(int i=0; i

{

a = (i+1)/1001.0;

}

for(int i=0; i

{

ipiv = -100;

}

info = LAPACK.dgetrf(n,n,a,n,ipiv);

Console.WriteLine("info on exit: " + info);

}

}

namespace mkl

{

public sealed class LAPACK

{

private LAPACK() {}

public static int dgetrf(int m, int n, double[] a, int lda, int[] ipiv)

{

int info = 0;

LAPACKNative.dgetrf(ref m, ref n, a, ref lda, ipiv, ref info);

return info;

}

}

[SuppressUnmanagedCodeSecurity]

internal sealed class LAPACKNative

{

private LAPACKNative() {}

[DllImport("mkl.dll", CallingConvention=CallingConvention.Cdecl)]

internal static extern void dgetrf(ref int m, ref int n, [In, Out] double[] a,

ref int lda, [Out] int[] ipiv, ref int info);

}

}

Regards,

--Vladimir

[thomasallin_dk]

Hi Vladimir,

thank you for the sample code.And yes, the problem appears to be solved.

As I understand, the problem size part was solved by going to version 10.2. The x86 / em64t issue was solved by creating a CLR assembly from the MKL libraries so that dllimports are no longer necessary. I essentially dissected the custom dll builder makefile and reintegrated it within avisual studio project. This approach makes it a lot easier to integrate and test new MKL functions during managed code development, and also ensures that all MS-specific dependencies are satisfied.

Best regards

Thomas