[cpp]#include
#include
#include
#include
#define N 2000
int main(int argc, char *argv[])
{
char jobz='V', range='I';
MKL_INT n=N;
double d, e ;
double vl=0.0, vu=0.1, abstol=0.000001;
MKL_INT il=1, iu=10, m=0, ldz=N;
double w, z[N*N], work[18*N];
MKL_INT isuppz[2*N], iwork[10*N];
MKL_INT liwork=10*N, lwork=18*N;
MKL_INT info=0;
double duration;
MKL_INT i;
clock_t start, finish;
for(i=0;i{
d=4.0;
e=1.0;
}
start = clock();
dstegr_(&jobz,&range,&n,d,e,&vl,&vu,&il,&iu,&abstol,&m,w,z,&ldz,isuppz,work,&lwork,iwork,&liwork,&info);
finish = clock();
duration = (double)(finish - start) / CLOCKS_PER_SEC;
printf( "%f seconds\n", duration );
for(i=0;i<10;i++)
printf("%.8f:%f:%.8f\n",d,e,w);
return(0);
}
[/cpp]
Link Copied
So, I have changed my code again in dynamic allocation mode, like this:
[bash]#include#include #include #define N 2000 int main(int argc, char *argv[]) { char jobz='V', range='I'; double *d, *e, *w, *z, *work; double vl=0.0, vu=0.1, abstol=0.000001; MKL_INT n=N, il=1, iu=10, m=0, ldz=N, info=0; MKL_INT *isuppz, *iwork, liwork=10*N, lwork=18*N; double duration; MKL_INT i; clock_t start, finish; d=(double*)malloc(N*sizeof(double)); e=(double*)malloc(N*sizeof(double)); w=(double*)malloc(N*sizeof(double)); z=(double*)malloc(N*N*sizeof(double)); work=(double*)malloc(18*N*sizeof(double)); iwork=(MKL_INT *)malloc(10*N*sizeof(MKL_INT)); isuppz=(MKL_INT *)malloc(2*N*sizeof(MKL_INT)); for(i=0;i =4.0; e=1.0; } start = clock(); dstegr_(&jobz,&range,&n,d,e,&vl,&vu,&il,&iu,&abstol,&m,w,z,&ldz,isuppz,work,&lwork,iwork,&liwork,&info); finish = clock(); duration = (double)(finish - start) / CLOCKS_PER_SEC; printf( "%f secondsn", duration ); for(i=0;i<10;i++) printf("%.8f:%f:%.8fn",d,e,w); free(isuppz); free(iwork); free(work); free(z); free(w); free(d); free(e); return(0); }
[/bash]
compile the code:
icc -g -o tri tri.c -I$MKLROOT/include -L$MKLROOT/lib/em64t
-Wl,-Bstatic -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5
-lpthread
then run again:
0.010000 seconds
1.99999754:0.500001:2.00000246
1.49999692:0.666668:2.00000986
1.33332950:0.750002:2.00002218
1.24999538:0.800003:2.00003944
1.19999458:0.833337:2.00006162
1.16666044:0.857147:2.00008874
1.14285010:0.875005:2.00012078
1.12499215:0.888895:2.00015775
1.11110244:0.900007:2.00019966
1.09999051:0.909099:2.00024649
Segmentation fault
Even if I added a printf before the return function of the program, the info CAN be prinited out correctly.
I guess the function made some modification in the stack, so functions cann't return normally.
Yes. It's the same problem we met on the latter two machines I had introduced in my last post. It occurs in 10.2 or newer MKL.
In 10.1, things looks quite good until the caller function returns.
The MKL Link Line Advisor is quite a good and interest tool, thank you!
I do not advise to use function dstegr. See http://software.intel.com/en-us/forums/showthread.php?t=73653&o=d&s=lr
I updated the MKL to 10.3 update 3 last night (the E7-4870 machine with RHEL 6 x64), and seg fault is still there.
Is it possible that the problem has relationship with compiler/glibc/kernel/linux distribution/other libs?
I updated the MKL to 10.3 update 3 last night (the E7-4870 machine with RHEL 6 x64), and seg fault is still there.
Is it possible that the problem has relationship with compiler/glibc/kernel/linux distribution/other libs?
Just now I tried install MKL 10.3 update3 on the Xeon 5450 RHEL 5.1 machine and didn't work neither...
2. Stack size is not the key point. Dynamic allocation of memory also made seg fault.
2. Stack size is not the key point. Dynamic allocation of memory also made seg fault.
It is used in a solver package named PSEPS (Parallel Symmetric Eigenvalue Package of Solver) which is developed by my collegue. I really know nothing about the scientific meaning and how and why he use the function. My duty is to maintain the machines and the system environments. Anyway, I had told him about your suggestion. Thank you!
That's really good news for me. I'll wait for the solution.
Thanks all!
For more complete information about compiler optimizations, see our Optimization Notice.