mkl_sparse_d_svd running unexpectedly slowly for large problems

[ChrisCX]

I've modified the mkl_sparse_d_svd example from mkl 2023.0.0 to use a much larger matrix and it's running surprisingly slowly on my machine compared to running the same problem in python using svds from scipy.sparse. 

Can anyone see what I'm doing wrong or confirm that this same example is also slow for them?

The code in the zip file is a basically unchanged copy of the mkl_sparse_d_svd.c example except with 4Mb of arrays declared at the top. 

The differences to the original example are the matrix shape:

descr.type = SPARSE_MATRIX_TYPE_SYMMETRIC;
descr.mode = SPARSE_FILL_MODE_UPPER;
descr.diag = SPARSE_DIAG_NON_UNIT;

and the options are now:
pm[1] = tol;
pm[2] = 2;
pm[6] = compute_vectors;
pm[7] = 1;

the number of singular values to compute is declared as a #define at the top:
#define xK0 25

I compiled it without any special options and linked with /STACK:50000000 against mkl_intel_lp64_dll.lib mkl_intel_thread_dll.lib mkl_core_dll.lib

The runtime for me is several minutes compared to seconds running the same matrix through svds, but they do report the same singular values at the end. 

Apologies for the horrific example code, it was just the easiest way to reproduce a problem I'm having locally in code I cant easily put here. 

[Sergey_K_Intel1]

Hi,

Thank you for posting in the oneMKL forum. I'd suggest to use pm[2]=1 (the Krylov-Schur method) for your case. It works very fast. There is a minor mistake in your reproducer which might cause segmentation fault.  The line
double Y[3*3]; 
should be changed to
double Y[25*25]; 
or  the array Y should be allocated just after finishing mkl_sparse_d_svd. 

The algorithm for pm[2]=2 is recommended  mostly  for cases where matrix-vector operations  are not expensive and spectrum is not too irregularly distributed.   

Thanks