Although Intel MKL speeds up calculations in GNU Octave, the results are sometimes (tested with Octave 5.2.0 in Xubuntu 20.04) totally wrong when the size of the Matrices are big. This has been mentioned here and here.
For example, this gist shows an example that Octave and Scilab produce different results, and the Octave's result is wrong (it changes every time the script is run. Octave gives correct result with OpenBLAS).
This is the code in the gist.
for a = 1:500
for b = 1:500
c(a,b) = sin(a + b^2);
endfor
endfor
g = eig(c);
m = max(real(g))
%Correct result is ans = 16.915
%With MKL in Ubuntu 20.04, I get random numbers of order 10^5 - 10^6, which changes on every run
How to fix this issue?
This issue has been mentioned in some Debian bug reports (see this and this), and a bug report in Octave.
According to the Debian maintainers, this is neither a bug of Octave, nor of MKL. It arises due to a racing condition between libgomp and libiomp.
Here's how to fix it.
Enter the command
export MKL_THREADING_LAYER=gnu
in a terminal, and call octave
from the same terminal. Now the issue should not arise.
To make this fix permanent, add the line export MKL_THREADING_LAYER=gnu
to your .bashrc
file.
Note: After installing MKL, I plotted a certain graph, and found something was seriously wrong (although the calculations were faster). I posted it in the MKL community, and they said it's not their bug. Finally I opened a bug report with Octave and someone mentioned this workaround.
Warning: As mentioned in the bug report, the test suite of Octave (__run_test_suite__
) fails with segmentation fault even when this workaround is applied. Therefore, it is advised that Octave with MKL is used with caution.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With