5

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?

  • Is this more relevant in Ask Ubuntu than Stack Overflow? – Archisman Panigrahi Aug 11 '20 at 06:52
  • If you are installing the MKL according to the second link in your question, then I note this is not the [official instructions provided by intel](https://software.intel.com/content/www/us/en/develop/articles/using-intel-mkl-in-gnu-octave.html). Have you tried to see if their method produces correct results? – Tasos Papastylianou Aug 11 '20 at 08:40
  • Also, I hasten to add ... what does "gives the correct result" mean? Gives the same result as another program which uses OpenBLAS? Who's to say the bug isn't with OpenBLAS? – Tasos Papastylianou Aug 11 '20 at 08:41
  • 1
    I used the `intel-mkl` package from Ubuntu repositories, and chose it as default BLAS library. I did not want to build Octave from source, (which is there in the official instructions by Intel). Octave's results keep changing on every run when MKL is used. Scilab with MKL, Octave with OpenBLAS, and [Fortran with MKL](https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Library/GNU-Octave-gives-different-results-with-MKL/m-p/1198890/highlight/true#M29885) produce the concurrent result 16.915 – Archisman Panigrahi Aug 11 '20 at 09:20

1 Answers1

5

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.