- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Gennady Fedorov (Intel)
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Michael,
Can you get us the example for reprpoducing and further invetsigating the problem?
What MKL version you are using? Please finddocmklupport.txt file and provide Package ID string
(you can find there something like Package ID: w_mkl_p_10.1.1.022 ).
--Gennady
Can you get us the example for reprpoducing and further invetsigating the problem?
What MKL version you are using? Please find
(you can find there something like Package ID: w_mkl_p_10.1.1.022 ).
--Gennady
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Gennady Fedorov (Intel)
Hi Michael,
Can you get us the example for reprpoducing and further invetsigating the problem?
What MKL version you are using? Please finddocmklupport.txt file and provide Package ID string
(you can find there something like Package ID: w_mkl_p_10.1.1.022 ).
--Gennady
Can you get us the example for reprpoducing and further invetsigating the problem?
What MKL version you are using? Please find
(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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Gennady Fedorov (Intel)
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
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 |
||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||
|
Thanks.
Michael

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page