Why is MLK much slower than LAPACK++ in symmetric eigen decomposition?

Why is MLK much slower than LAPACK++ in symmetric eigen decomposition?

Hi,

I am seeing that the MLK function dsyev() is about six times slower than the LAPACK++ function LaEigSolve() - even though LaEigSolve() just calls the dsyev() from the LAPACK package.

Calculation times: finding all eigenvectors of 3000 x 3000 matrix: MLK - 225 sec, LAPACK++ - 34 sec.

What am I doing wrong? Is the block size not set correctly?

Peter

3 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Your question is a good one. I am asking one of our several LAPACK experts to respond to this question. In general, MKL has been concentrating on improving the performance of LAPACK routines that are in deficit to both the netlib versions and other library versions. We use a method called s-curves to represent the data. Essentially this is a curve created but taking the ratios of performanc (or inverse time), ordering the resulting data and plotting it. It is our goal to have lots of values greater than 1.0, few that are less than 1.0, and those that are less than 1.0 should be close to 1.0. Were you to do that with MKL 9.1, for instance and compare it to MKL 9.0 you would see a dramatic improvement overall in the LAPACK performance.

Bruce

Hi Peter,

probably you need to use -ftz compiler flag to get the best performance. MKL DSYEV routine applies fast eigenvectors update, but when the eigenvector components become too small (denormals, in fact), the exception handler may be invoked depending on the CPU flag set - that slows down the computation. -ftz treats denormals as zerosthat isno handler is invoked.

The issue could be also if you're too close tothe memory restriction, thenmake sure that the comparative data look similar at 1000 or 2000. Swapping may take a lot of time if the physical memory is not enough.

If it doesn't help, I'd recommend you to submit an issue over QuAD against MKL eigensolver.

Michael,

Intel MKL engineer

Leave a Comment

Please sign in to add a comment. Not a member? Join today