Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.
6982 Discussions

MKL Kernel calling wrong dll - CPU Dispatch issue

MikeLevine
Beginner
505 Views
I have been working on a project using MKL, statically linked (except for openmp). I didn't make any code changes, but all of a sudden calling LAPACK function dgesv would result in a quasi-infinite loop. The problem only appears once the matrices involved reach a certain size. I did not try and determine the exact dimensions for which the factorization fails.

To solve the problem, I switched all the libraries to dynamically linked. I included the *p4n.dll files in the project build folder and that seemed to remove the limit on the size of the matrices.

The problem that I'm noticing now is that mkl_core_dll.lib seems to call *def.dll functions instead of the *p4n.dll files. The system is running Vista x64, 6GB of RAM, 1xIntel 5130 Xeon processor.

I have updated to the latest version of all MKL libraries. Any idea why a) the static libraries fail? b) the dynamic libraries do not use the Xeon libraries? How can I fix this?

If you need any more information, please let me know and I'll try and give you what I can.

Thanks and regards,
Michael
0 Kudos
6 Replies
Gennady_F_Intel
Moderator
505 Views
Michael,
1.There are no restrictions with static library libraries (more precisely these restrictions depend on RAM available on your system).
2. if mkls libraries you used for linking your application are correct, then mkls dispatching will work correctly and dynamic libraries will use Xeon related libs.
So, first of all, let me your linking dependencies were used for both (static and dynamic cases )
--Gennady

0 Kudos
MikeLevine
Beginner
505 Views
Michael,
1.There are no restrictions with static library libraries (more precisely these restrictions depend on RAM available on your system).
2. if mkls libraries you used for linking your application are correct, then mkls dispatching will work correctly and dynamic libraries will use Xeon related libs.
So, first of all, let me your linking dependencies were used for both (static and dynamic cases )
--Gennady


I didn't imagine that there should bea difference between the static and dynamic libraries. My machine has plenty of RAM - 6GB (running Vista x64) and the private working space for my executable was under 1GB, with about 3.5GB of free RAM available. In any event, I had always preferred the dynamic linking - I just wasn't able to get it to work, until I realized that it was looking for the default libs - not the Xeon libs.

I'm running VS2008, doesn't matter whether I use Intel's or MS compiler. My dependencies are (for dynamic linking)

mkl_intel_thread_dll.lib libiomp5md.lib mkl_intel_lp64_dll.lib mkl_core_dll.lib

I have copies of the dll files from the latest MKL update in my build folder.

Unfortunately, I have already overwritten the dependency list for the static linking and I will have to retrieve from a backup if it's important. In any event, as before, I'm happier with the dynamic linking. I'll be even happier though when it uses the right libs.

Thanks again for your help.
Michael
0 Kudos
Gennady_F_Intel
Moderator
505 Views
Hi Michael,
Can you get us the example for reprpoducing and further invetsigating the problem?
What MKL version you are using? Please find docmklupport.txt file and provide Package ID string
(you can find there something like Package ID: w_mkl_p_10.1.1.022 ).
--Gennady

0 Kudos
MikeLevine
Beginner
504 Views
Hi Michael,
Can you get us the example for reprpoducing and further invetsigating the problem?
What MKL version you are using? Please find docmklupport.txt file and provide Package ID string
(you can find there something like Package ID: w_mkl_p_10.1.1.022 ).
--Gennady


Package ID: w_mkl_p_10.1.1.022
Package Contents: Intel Math Kernel Library 10.1 Update 1 for Windows*

As for an example - I'm not sure exactly what you are looking for. Could using OMP within my code have any effect here?

Here's a chunk of my code from the file where I have noticed the issue:

[cpp]#include "Neural.h"
#include "matrix.h"
#include "math.h"
#include "stdafx.h"
#include "mkl_service.h"
#include "omp.h"
#include "mkl_vml_functions.h"[/cpp]
extern "C"
{
//Matrix-Matrix Multiplication
void dgemm(char *, char *, int *m, int *n, int *k, double *alpha, double *a, int *lda, double *b, int *ldb, double *beta, double *c, int *ldc);
//Matrix-Vector Multiplication
void dgemv(char *, int *m, int *n, double *alpha, double *a, int *lda, double *x, int *incx, double *beta, double *y, int *incy);
}

...

//Calculate Hessian Matrix
dgemm("T", "N", &nWeights, &nWeights, &trainingPairs, &const_one, J.stuff, &trainingPairs, J.stuff, &trainingPairs, μ, Ident.stuff, &nWeights);


Stopping the code in the middle of the execution of this line of code, the call stack shows the following:
mkl_def.dll
[Frames below may be incorrect and/or missing, no symbols loaded for mkl_def.dll]
mkl_def.dll
mkl_intel_thread.dll
mkl_intel_thread.dll
libiomp5md.dll

Please let me know if there's any more information that I can give you. Is there a service function that returns the cpu id, or instruction sets, etc?

Thanks for your help,
Michael
0 Kudos
Gennady_F_Intel
Moderator
505 Views
Michael,
Your original request was regarding dgesv but not dgemm.
1. you reported that you got quasi-infinite loop with a certain size while static linking mode was using.
Its critical for us to understand the cause of this problem, so why first of we d like to know the size
2.if you are interesting in dynamic linking - we can check which *.dll will be call.
3. Is there a service function that returns the cpu id, or instruction sets, etc?
You can use, for example the following routine for checking

int version(void) {
MKLVersion Version;
MKLGetVersion(&Version);
printf("Major version: %dn",Version.MajorVersion);
printf("Minor version: %dn",Version.MinorVersion);
printf("Update number:%dn",Version.BuildNumber);
printf("Product status: %sn",Version.ProductStatus);
printf("Build: %sn",Version.Build);
printf("Processor optimization: %sn",Version.Processor);
}//

You can have something like below:

Major version: 10
Minor version: 1
Update number:0
Product status: Product
Build: 082609.15
Processor optimization: Intel Core 2 Duo Processor

Press any key to continue . . .
+++++++++++++++++++++++++++++
Please pay attention on the line
Processor optimization: Intel Core 2 Duo Processor

If your processor was not recognized by MKLs CPU dispatcher then you will see:
Processor optimization: Default processor

--Gennady





0 Kudos
MikeLevine
Beginner
505 Views
Michael,
Your original request was regarding dgesv but not dgemm.
1. you reported that you got quasi-infinite loop with a certain size while static linking mode was using.
Its critical for us to understand the cause of this problem, so why first of we d like to know the size
2.if you are interesting in dynamic linking - we can check which *.dll will be call.
3. Is there a service function that returns the cpu id, or instruction sets, etc?
You can use, for example the following routine for checking

int version(void) {
MKLVersion Version;
MKLGetVersion(&Version);
printf("Major version: %dn",Version.MajorVersion);
printf("Minor version: %dn",Version.MinorVersion);
printf("Update number:%dn",Version.BuildNumber);
printf("Product status: %sn",Version.ProductStatus);
printf("Build: %sn",Version.Build);
printf("Processor optimization: %sn",Version.Processor);
}//

You can have something like below:

Major version: 10
Minor version: 1
Update number:0
Product status: Product
Build: 082609.15
Processor optimization: Intel Core 2 Duo Processor

Press any key to continue . . .
+++++++++++++++++++++++++++++
Please pay attention on the line
Processor optimization: Intel Core 2 Duo Processor

If your processor was not recognized by MKLs CPU dispatcher then you will see:
Processor optimization: Default processor

--Gennady






Well, it's a little better now - I added /bin folder to my PATH variable and now it seems to recognize my processor as Core 2 Duo, and it calls MKL_mc.dll. It's also running quite a bit slower than before.

Interestingly, I was looking at my environment variables and PROCESSOR_ARCHITECTURE is set to AMD64. I tried changing it to EM64T, but it changed back automatically when I rebooted the machine. I wonder if this is causing something strange?

The output from the function above that you posted is:
Major version: 10
Minor version: 1
Update number:1
Product status: Product
Build: 082212.12
Processor optimization: Intel Core 2 Duo Processor

CPU-Z shows me the following:

CPU-Z 1.50 report file

Processor(s)
Number of processors 1
Number of cores 2 per processor
Number of threads 2 per processor
Name Intel Xeon 5130
Code Name Woodcrest
Specification Intel Xeon CPU 5130 @ 2.00GHz
Package Socket 771 LGA
Family/Model/Stepping 6.F.6
Extended Family/Model 6.F
Core Stepping B2
Technology 65 nm
Core Speed 1995.0 MHz
Multiplier x Bus speed 6.0 x 332.5 MHz
Rated Bus speed 1330.0 MHz
Stock frequency 2000 MHz
Instruction sets MMX, SSE, SSE2, SSE3, SSSE3, EM64T
L1 Data cache (per processor) 2 x 32 KBytes, 8-way set associative, 64-byte line size
L1 Instruction cache (per processor) 2 x 32 KBytes, 8-way set associative, 64-byte line size
L2 cache (per processor) 4096 KBytes, 16-way set associative, 64-byte line size

Thanks.
Michael
0 Kudos
Reply