Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.
6621 Discussions

LAPACKE_dgeev result differences on different CPU architectures


Hi, I am using MKL 11.1 to find eigen vectors with and am having issues with the results changing sign depending on which machine I run this. This gives completely different results in the end for an ellipse fitting algorithm and, thus, failures in automated tests.

Given the following matrix in row major order:

-8747596.5053710938      -316030.00427246094       1615084.5202636719
-5749756.8850097656      -667037.37084960938       632059.98022460938
 52358865.204467773       2874878.4188232422      -8747596.5129394531

The following call is made:

auto squareSize = 3;
auto info = LAPACKE_dgeev( LAPACK_ROW_MAJOR, 'N', 'V', squareSize, 
  inputArrayOutput.Data(), squareSize, 
  realEigenValues.Data(), imaginaryEigenValues.Data(), 
  nullptr, squareSize, rightEigenVectors.Data(), squareSize );

Running this on machines that give the "correct" or expected result will give.

-18162659.389763702       -4492507.6042798907      -5290349.3859531470
 0.00000000000000000       214.50030177488844       915701.07938791020
 0.00000000000000000      -0.0070577840503023292    214.50030177488844
real eigenvalues
-18162659.389763702        214.50030177488844       214.50030177488844 
imag eigenvalues
0.00000000000000000        80.391669176281070      -80.391669176281070  
right eigenvectors
 0.17135077952698607       0.15755967091010539     -6.3641462760426620e-06
 0.091750438224901587     -0.67430368000587571      0.00013608158502213653
-0.98092852310503897       0.72144956765842805      0.00000000000000000

But on a "failing" machine this will give something like:

-18162659.389763702        4492507.6042798860      -5290349.3859531470
 0.00000000000000000       214.50030177486741      -915701.07938790950
 0.00000000000000000       0.0070577836735623567    214.50030177486741
real eigenvalues
-18162659.389763702        214.50030177486741       214.50030177486741 
imag eigenvalues
 0.00000000000000000       80.391667030653210      -80.391667030653210 
right eigenvectors
 0.17135077952698605      -0.15755967091010534      6.3641461061856458e-06
 0.091750438224901559      0.67430368000587682     -0.00013608158139016290
-0.98092852310503875      -0.72144956765842760      0.00000000000000000

As can be seen the sign of the last two right eigen vectors changes. The question then is why? And how can one correct this sign change so the result will always have the same sign? It seems to be correlated to the output in "inputAndOutput" but how?

Or is this in fact a bug and would a later MKL version fix this?


0 Kudos
4 Replies

Hi Harry,

Eigenvectors returned by DGEEV are normalized and have largest component real, but the sign of the eigenvectors is not defined.

If you need bitwise reproducible results (perhaps at a performance tradeoff), please refer to conditional numerical reproducibility feature of Intel MKL, here.



Hi Dmitry, thanks for the reply. Ok I should try that then, since we are targetting SSE2 or later processors I assume I should call "mkl_cbwr_set(MKL_CBWR_SSE2)". Any data on how much slower this might be?


Hi, we have examining this more closely and it appears this issue only occurs when MKL is run on a virtual machine, are there any known issues with regard to using MKL on virtual machines? Does CPU dispatching not work?


Hi Harry,

Intel MKL supports only so-called run-to-run reproducibility of results. It means that running twice your application on any particular machine, you'll get bit-wise identical results (keeping the enviroment the same). There's no guarantee that you'll be able to get this on different machines even with CBWR feature set to the same value (as many parameters like number of threads, cache size etc. matter).

So, I recommend you to use MKL_CBWR_AUTO as it will work for any instruction set you're running at the moment. For example, at AVX2 machines it will give much better performance comparing to MKL_CBWR_SSE2.

Regards, Konstantin