topic Re: Confirm multi-threaded compatibility in Intel® oneAPI Math Kernel Library

Confirm multi-threaded compatibility

yevs19 — Tue, 08 Jan 2008 00:33:34 GMT

Hi,

We are building a custom MKL 10.0.012 DLL for IA32, to be called by our C# .NET 2005 application via PInvoke.

We are using the builder tool, with stdcall and a def file.

Our application uses Windows Forms and is multi-threaded (we call VML functions from multiple threads).

I found the documentation a bit confusing here; I got the impression that if the builder tool linked mkl_intel_thread.lib and libiomp5md.lib, then we would be able to use the resulting multi-threaded custom DLL with our .NET application. Unfortunately, when we run the application on a multi-core machine, the software crashes without many diagnostics when the custom MKL DLL is invoked.

We are able to build and run successfully by just linking mkl_sequential.lib - but I wanted to clarify whether we would be able to use the multi-threaded layer.

Thanks and regards.

Re: Confirm multi-threaded compatibility

TimP — Tue, 08 Jan 2008 14:21:48 GMT

If your upper level threading doesn't use OpenMP, I can see the MKL threading having difficulty tracking the number of threads. If there were trouble caused by each .dll attempting to initialize OpenMP, you should get the warning about multiple initializations, which means you are in unsupported territory. I doubt that your scenario is well tested. If you know how many threads you want used by MKL, you should set that number in OMP_NUM_THREADS environment variable.

Re: Confirm multi-threaded compatibility

Andrey_G_Intel2 — Tue, 08 Jan 2008 14:34:05 GMT

could you try to use libguide40.lib instead libiomp5md.lib?

Re: Confirm multi-threaded compatibility

yevs19 — Mon, 21 Jan 2008 03:21:08 GMT

Setting OMP_NUM_THREADS to 1 allows the application to run without errors (albeit with the same performance characteristics as mkl_sequential?)

Setting OMP_NUM_THREADS to 2+ causes the application to fail as before.

Re: Confirm multi-threaded compatibility

yevs19 — Mon, 21 Jan 2008 03:21:59 GMT

Unfortunately, using libguide40 didn't seem to make any difference here.

Re: Confirm multi-threaded compatibility

Todd_R_Intel — Wed, 18 Jun 2008 22:43:08 GMT

There was a DLL builder bug fixed in update 3 which is available now. I'm afraid I can't promise it will address your issue based on the info on this thread, but I mention it in case you're up for the experiment.
-Tod

Re: Confirm multi-threaded compatibility

Intel_C_Intel — Mon, 30 Jun 2008 06:54:46 GMT

I tried again with Update 3 but still having access violations whenever I call anything from VML. Can I find out specifically what memory issue the update addressed?