I have been testing the speed of the Fortran compiled (with -O2 optimization using the Intel 10 Fortran compiler) lapack (from netlib)version of DGBTRF (LAPACK square dense linear solver) against the MKL version.
I was very suprised to discoverthat MKL is up to 4 or 5 times slower than the Fortran compiled in the case where the matrix becomes sparse.
I am guessing that the MKL implementation of this routine uses machine code and exploitation of the cache and pipeline, but at the cost of not avoiding arithmetic operations for zero entries in the matrix. This works fine for purelydense ("full")problems, but there will be a cross-over point where the Fortran compiled LAPACK version will beat the MKL impementation when the matrix becomes sparse.My questions are: is my theory correct and what is the crossover point?
Of course, for sparse matrices I shouldnt be using LAPACKat all and instead be using a sparse solver. However, our use case of our application is that the matrix size and sparsity is model and application dependent - we dont know until run time what the size and sparsity is going to be. Ideallywe would like to know under what size N and what number of non-zeros NZ we should switch from MKL LAPACK to the Fortran compiled LAPACK and then to sparse solver outright.
Any advice or comments on my theory are most appreciated.