- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
MKL 10.3 update 5 has made many strides over previous versions in fixing data races in multi-thread applications. I run tests on my code under Intel Inspector XE , and the data races inside MKL are almost gone
... EXCEPT for this one that keeps cropping up. I do not believe it is a "harmless" data race. They never are...
This needs to run with OpenMP on, obviously.
ID Problem Sources Modules State
P1 Data race testzgetrf.cpp testzgetrf.exe New
The actual data race (write) is at this location.
mkl_core.dll!mkl_serv_deallocate - mkl_core.dll:4937
testzgetrf.exe!zgetrf - testzgetrf.exe:6101
testzgetrf.exe!test - testzgetrf.cpp:27
... EXCEPT for this one that keeps cropping up. I do not believe it is a "harmless" data race. They never are...
This needs to run with OpenMP on, obviously.
ID Problem Sources Modules State
P1 Data race testzgetrf.cpp testzgetrf.exe New
The actual data race (write) is at this location.
mkl_core.dll!mkl_serv_deallocate - mkl_core.dll:4937
testzgetrf.exe!zgetrf - testzgetrf.exe:6101
testzgetrf.exe!test - testzgetrf.cpp:27
[cpp]#include "mkl_lapack.h" #includevoid test() { #define NSIZE 20 #pragma omp parallel for for( int iLoop=0;iLoop<20;iLoop++){ MKL_Complex16 a[NSIZE][NSIZE]; for( int i=0;i .real=1; a .imag=0; }else{ a .real=0; a .imag=0; } } } int M = NSIZE; int N = NSIZE; int info; int ipvt[NSIZE]; zgetrf(&M, &N, (MKL_Complex16 *)a, &M, ipvt, &info); //std::cout << info << std::endl; } } int main(int argc, char * argv[]) { test(); return 0; } [/cpp]
Link Copied
7 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
MKL_Complex16a[NSIZE][NSIZE];??????????
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
And your point is what?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is an one-dimensional array.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
zgetrf expects a NxM matrix of complex double.
It declares a block of memory that can be though of as a one-d array [NSIZE*NSIZE] or a 2D array [NSIZE][NSIZE], lapack does not care how you declare your memory as long as the layout is column major, and since my array is square that is not an issue.
It declares a block of memory that can be though of as a one-d array [NSIZE*NSIZE] or a 2D array [NSIZE][NSIZE], lapack does not care how you declare your memory as long as the layout is column major, and since my array is square that is not an issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Very interesting. I did not know it. Tell explicitly as storage for a two-dimensional array is selected.
This selection of storage depends on the translator?
This selection of storage depends on the translator?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is this a Turing test? And way off-topic
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I hinted that you are mistaken. Consider an example of the fragmented storage.

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