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.
Related
I’m having a problem with printing figures in octave when the figure’s visibility is set to false. For example, the following code produces a “panic: segmentation fault” in Octave version 4.2.2:
t = 1:10;
fh = figure(“visible”, false);
plot(t,sin(t))
print(“fig.png”)
If I run the above code in Octave version 5.2.0, there is no problem. Is this a bug that was fixed in the Octave 5 update? If so, is there a workaround that I can use for Octave 4? I would prefer to use Octave 4 if possible.
Other notes:
I am running this in Ubuntu 16.04.6 LTS and I installed octave 4 using apt.
The answer to your question is, yes. Here is the relevant line from the v5.1.0 NEWS:
Dependencies:
The GUI requires Qt libraries. The minimum Qt4 version supported is Qt4.8. Qt5 of any version is preferred.
The OSMesa library is no longer used. To print invisible figures when using OpenGL graphics, the Qt QOFFSCREENSURFACE feature must be available and you must use the qt graphics toolkit.
Apparently the now deprecated OSMESA dependency and the printing of invisible figures was a long-standing pain-in-the-butt. Maybe you'll have some luck going through bug comments (e.g. someone says that if you make it visible at least once, it may be possible to print).
But as people have said in the comments, the best thing to do would be to upgrade your octave version, and recompile your mexfiles for the new version.
Does anyone ever succeeded in installing MAtConvNet under Octave ?
If so could you please let me know the steps to proceed ?
thanks and regards
Arno
I was just looking into this issue myself. I have reached a point in researching this where I feel the issues are too complicated for my own project and are not worth my time trying to finish running down. However, if someone else is determined to track this down, hopefully this information will help.
The basic problem comes down Octave only compiling to support 32-bit architectures even if you use the 64-bit installer. If you want Octave to support 64-bit, you need to compile from source using the appropriate compiling options. The other details are as follows.
MatConvNet appears to require a 64-bit system to compile.
http://www.vlfeat.org/matconvnet/mfiles/vl_compilenn/
MatConvNet detects system architecture in in the mex_cuda_config function in vl_compilenn.m:
https://github.com/vlfeat/matconvnet/blob/master/matlab/vl_compilenn.m
Octave's computer function is not a perfect analog to Matlab's function, so the mex_cuda_config function in vl_compilenn.m would need to be modified or Octave's computer function would need to be updated. More specifically, the computer function's handling of the 'arch' argument needs to be changed.
There may be other issues, but this is where I would start if I had the time to invest in trying to track this down.
After quite a bit of searching and trying different things, I am stumped on how to get mym to work (as found here: http://sourceforge.net/projects/mym/). I was wondering if anyone has a very simple list of actions needed to get this to work. I think my main trouble is installing zlib. I don't understand how to actually install it or work with it. I have tried to use Microsoft Visual C++ Express 2010 but then only the debug versions are compiled. That means when I try to use the mex function in matlab it gives me the error:
Error: Could not detect a compiler on local system
which can compile the specified input file(s)
I just don't understand the process and everywhere I look it says something different. I have tried multiple versions of each all of the programs involved and nothing seems to work. Any help would be greatly appreciated.
Do:
mex -setup
from the command line to define your compiler on your system. Once you do that then Matlab will correctly locate the compiler and build the mex libraries it needs.
See:
http://www.mathworks.com/help/matlab/matlab_external/building-mex-files.html
I need to use the CobraToolbox for a course and I am wondering if it is compatible with Octave.
Even googling for this doesn't return much results..
Thanks in advance
Unless someone has published their results, you can't know without trying it. However, there is a very high likelihood that it will work on Octave, here's what Jordi has to say on this issue answering this question.
I am new to Octave and was wondering if it is possible to use matlab
toolboxes in Octave?
It depends on what you mean by "Matlab toolbox". If you mean the code
that came with Matlab, it's probably a license violation to use it
with Octave, assuming you can compile it for Octave when it's
necessary to compile.
If you mean free code out there you found on the internet that was
written for Matlab, it is likely it will work on Octave. Just try it.
If you need to compile mex files, the "mkoctfile --mex" command may be
of use.
If you want to have a rough equivalent of the Matlab toolboxes in
Octave, try the Octave-Forge packages:
My personal experience is that Octave has become extremely good at accepting Matlab code. I would hazard a guess that any time you spend setting up Octave and this toolbox will be worth it. Even the MEX files appear to have a portability mechanism. Unless they are using some very specific features like addpref for toolbox persistent data, it will slide right into Octave. Even if they are using the prefs, it could be modified to live in Octave.
In order to distribute a function I've written that depends on other functions I've written that have their own dependencies and so on without distributing every m-file I have ever written, I need to figure out what the full list of dependencies is for a given m-file. Is there a built-in/freely downloadable way to do this?
Specifically I am interested in solutions for MATLAB 7.4.0 (R2007a), but if there is a different way to do it in older versions, by all means please add them here.
For newer releases of Matlab (eg 2007 or 2008) you could use the built in functions:
mlint
dependency report and
coverage report
Another option is to use Matlab's profiler. The command is profile, it can also be used to track dependencies. To use profile, you could do
>> profile on % turn profiling on
>> foo; % entry point to your matlab function or script
>> profile off % turn profiling off
>> profview % view the report
If profiler is not available, then perhaps the following two functions are (for pre-MATLAB 2015a):
depfun
depdir
For example,
>> deps = depfun('foo');
gives a structure, deps, that contains all the dependencies of foo.m.
From answers 2, and 3, newer versions of MATLAB (post 2015a) use matlab.codetools.requiredFilesAndProducts instead.
See answers
EDIT:
Caveats thanks to #Mike Katz comments
Remember that the Profiler will only
show you files that were actually used
in those runs, so if you don't go
through every branch, you may have
additional dependencies. The
dependency report is a good tool, but
only resolves static dependencies on
the path and just for the files in a
single directory.
Depfun is more reliable but gives you
every possible thing it can think of,
and still misses LOAD's and EVAL's.
For MATLAB 2015a and later you should preferably look at matlab.codetools.requiredFilesAndProducts
or doc matlab.codetools.requiredFilesAndProducts
because depfun is marked to be removed in a future release.