version is a well-known Matlab function, which displays and returns information about the installed release:
>> [v,d] = version v = 8.1.0.604 (R2013a) d = February 15, 2013 >> version('-java') ans = Java 1.6.0_17-b04 with Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM mixed mode |
This is pretty boring stuff. But it starts to get interesting when we learn the undocumented fact that version can also report version information of the installed math libraries, starting in R2009b (Matlab 7.9):
% R2013a (Matlab 8.1) on Win7 64b >> version('-fftw') ans = FFTW-3.3.1-sse2-avx >> version('-blas') ans = Intel(R) Math Kernel Library Version 10.3.11 Product Build 20120606 for Intel(R) 64 architecture applications >> version('-lapack') ans = Intel(R) Math Kernel Library Version 10.3.11 Product Build 20120606 for Intel(R) 64 architecture applications Linear Algebra PACKage Version 3.4.1 |
This information is sometimes useful, and is sometimes asked by users. Specific versions of BLAS, LAPACK and FFTW, which Matlab uses under its hood for all linear algebra and FFW computations, may exhibit idiosyncrasies that may be important in certain cases.
In versions up to R2013a, this information could also be retrieved using the internal.matlab.language.versionPlugins.* mex functions (e.g., internal.matlab.language.versionPlugins.blas, which runs the mex function %matlabroot%\toolbox\matlab\matfun\+internal\+matlab\+language\+versionPlugins\blas.mexw64). I’ll have a separate post (or series of posts) on Matlab’s internal.* functions, but at least with regards to version information they should NOT be relied upon. These interfaces (and their mex files) have changed their name and availability in some Matlab releases. Luckily, the version format that I showed above seems pretty stable and can be used as-is across multiple Matlab releases.
Here is a summary of the math libraries version in recent Matlab releases (Windows only):
| Matlab release | FFTW | MKL (BLAS) | LAPACK |
|---|---|---|---|
| R2009b SP1 (7.9.1) | 3.2.0-sse2 | 10.2.2 (2009-08-14) | 3.1.1 |
| R2010a (7.10) | 3.2.2-sse2 | 10.2.2 (2009-08-14) | 3.2.1 |
| R2010b (7.11) | 3.2.2-sse2 | 10.2.3 (2009-11-30) | 3.2.1 |
| R2011a (7.12) | 3.2.2-sse2 | 10.2.6 (2010-07-28) | 3.2.2 |
| R2011b (7.13) | 3.2.2-sse2 | 10.3.2 (2011-01-17) | 3.2.2 |
| R2012a (7.14) | 3.2.2-sse2 | 10.3.5 (2011-07-20) | 3.3.1 |
| R2012b (8.0) | 3.3.1-sse2 | 10.3.9 (2012-01-31) | 3.3.1 |
| R2013a (8.1) | 3.3.1-sse2-avx | 10.3.11 (2012-06-06) | 3.4.1 |
Note that the LAPACK version is not always updated together with BLAS, although they are both part of Intel’s MKL (more on MKL below).
Addendum 2013-10-9: The undocumented -modules option of the version command provides the list of currently installed libraries:
>> version -modules C:\Program Files\Matlab\R2013b\bin\win64\libut.dll Version < unknown > C:\Program Files\Matlab\R2013b\bin\win64\libmwfl.dll Version < unknown > C:\Program Files\Matlab\R2013b\bin\win64\libmx.dll Version 8.2.0.627 C:\Program Files\Matlab\R2013b\bin\win64\zlib1.dll Version < unknown > ... |
[/Addendum]
Do you know of any other hidden version info anywhere in Matlab? If so, please post a comment below.
Upgrading library versions
It may well be possible for users to upgrade the internal libraries that Matlab uses to the latest version, assuming that backward compatibility is preserved in these libraries (which I suppose is the case). Naturally, you can only upgrade if you have a license for the upgraded library. For those interested, the libraries are located in %matlabroot%/bin/%arch%. For example: C:\Program Files\Matlab\R2013b\bin\win64\mkl.dll is Intel’s MKL (Math Kernel Library), which contains BLAS and LAPACK. Using this example, the latest official version of MKL is 11.0, which promises several important improvements over R2013a’s bundled version (10.3.11):
- A fix for a bug in the svd routines
- Improved performance
- Improved support for Intel’s AVX2 instruction set (see related comment by Eric Sampson recently)
- Improved functionality of MKL’s FFT implementation — Matlab’s *fft functions use FFTW, but in some cases MKL’s FFT implementation outperforms FFTW’s. You may wish to use MKL’s FFTW wrapper in such cases rather than calling MKL’s FFT routines directly.
Similarly, FFTW’s latest stable release is 3.3.3, offers advantages compared to R2013a’s bundled 3.3.1 version. Unfortunately, unlike MKL, FFTW is not bundled as a replaceable library file. I believe that FFTW is directly integrated in Matlab’s code. However, nothing prevents us from downloading the latest library and using it directly.
Needless to say, upgrading specific DLLs in Matlab can be extremely dangerous, and is entirely unsupported by MathWorks. Don’t come crying if Matlab starts to crash, or even worse – to return incorrect numerical results. If you design a car with upgraded libs, just let me know please, so that I’d know not to buy that model… I don’t often place such warnings on this blog. After all, this is a blog about undocumented / unsupported stuff. So when I do explicitly warn like this, you should take extra note. Upgrading Matlab’s math libs is purely an exercise for adventurous engineers who like to blow things up (oh, the sheer pleasure of charting undocumented waters!).
Addendum 2013-10-9: Amro’s comment below provides links to several articles that show how we can redirect Matlab to use a different BLAS/LAPACK library than the default (in MKL/ACML), by either setting the BLAS_VERSION environment variable or by updating the blas.spec and lapack.spec files in the libs folder. One user has reported that in his specific case this achieved a 30% speedup with no change to the code. Note that both of these options only apply to MKL/ACML, and not to other libraries – in those cases, AFAIK, only a direct replacement of the physical file will work. [/Addendum]
IPP library
If you have the Image Processing Toolbox (IPT), then you will also find Intel’s IPP (Integrated Performance Primitives) library (ippl.dll) in the same folder as mkl.dll. IPP is used by IPT for running some highly-optimized image-processing functions.
Unfortunately, I could not find a parameter of version that returns the IPP version used by Matlab. However, we can get IPP’s version info using the ippl function, which is a semi-documented function in IPT (i.e., it has detailed help, but for some reason not an official doc page):
% R2013a (Matlab 8.1) on Win7 64b >> [isIpplEnabled, ipplVersion] = ippl isIpplEnabled = 1 % == true ipplVersion = 'ippie9_t.lib 7.0 build 205.58 7.0.205.1054 e9 Apr 18 2011' |
A few IPP-related aspects that you might find interesting in this regard:
- Matlab currently (R2013a) uses IPPL 7.0 dated April 2011 – the latest version is 8.0 dated June 26, 2013 (only 3 weeks ago) includes significant performance boosts. Note that between 7.0 and 8.0 there was a 7.1 release that also had significant improvements, especially for modern CPUs. The 8.0 release changed some function names, so for compatibility with Matlab you might discover that you need to settle for the 7.1 DLL. This could still bring significant benefits.
- Matlab currently limits IPP usage to uints, floats and (since R2012b) doubles, although (AFAIK) IPP also supports signed ints. For signed ints Matlab reverts to much slower functional processing, which seems a pity. I’m not 100% certain that these are indeed supported by IPP for the specific cases in which Matlab currently blocks them, but I think it’s worth a check – the performance boost could be worth the effort.
- Matlab currently uses IPP only for some of the image-processing functions. It would make sense to use IPP much more widely, e.g. math, stats, convolution, FFT/FIR (I’m not sure it’s faster than FFTW, but it may be worth a check) and many others – IPP is much more versatile than an image processing toolkit (read here).
Even if we don’t upgrade the ippl.dll or mkl.dll version, we may still benefit by accessing them directly in Matlab and/or MEX code. They can be used in Matlab just like any other DLL. There are plenty of online resources that can help us program using the IPP/MKL functionalities, even on the Matlab CSSM newsgroup. It seems that quite a few Matlab users try to work directly with these libraries, sometimes perhaps not realizing that they are already pre-bundled within Matlab.
If you have successfully used one of these libraries directly in Matlab, and/or successfully upgraded the libs for some use, please share your experience by posting a comment below.
There is a section in the docs explaining how to call BLAS/LAPACK routines in MEX functions (linking against the versions that ship with MATLAB): http://www.mathworks.com/help/matlab/matlab_external/calling-lapack-and-blas-functions-from-mex-files.html
Also here is an oldie but goodie submission on FEX to interface with LAPACK: http://www.mathworks.com/matlabcentral/fileexchange/16777-lapack
The specified libs are static libs that are essentially MathWorks-generated wrappers for MKL’s internal BLAS, LAPACK functions. Instead of the libs, one could presumably link directly with mkl.dll.
Had MathWorks encapsulated BLAS and LAPACK in DLLs rather than libs, we could call them directly from m-code. Since MathWorks chose to use static libs, the libs can only be used in Matlab by linking them into a mex file. I’m not sure that I understand the logic of this decision. It doesn’t matter so much since we can directly use mkl.dll, which presumably includes everything that the static libs have.
Actually those *.lib files are considered import libraries [*], which are required in the case of MSVC compiler/linker. The actual implementation of the BLAS routines resides in the dynamically loaded library. On Linux/Mac, you can directly link against the shared library equivalent to DLLs (*.so files) without an import library.
[*]: https://en.wikipedia.org/wiki/Dynamic-link_library#Import_libraries
Some people in the past have successfully managed to run MATLAB with customized implementations of BLAS/LAPACK (ATLAS, GotoBLAS, OpenBLAS, ..). Here are some references for those interested:
https://www.mathworks.com/matlabcentral/newsreader/view_thread/129077
http://www.stanford.edu/~echu508/matlab.html
http://software.intel.com/en-us/articles/using-intel-mkl-with-matlab/
http://software.intel.com/en-us/articles/intel-math-kernel-library-intel-mkl-for-windows-using-intel-mkl-in-matlab-executable-mex-files/
Back in v6 and earlier (I think), MATLAB used ATLAS as BLAS implementation, before switching to Intel MKL starting with v7:
http://www.mathworks.com/company/newsletters/articles/matlab-incorporates-lapack.html
It should be noted that MKL is highly optimized for Intel processors, and it’s hard to get large performance gains over the vendor’s own implementation..
@Amro – Thanks for the numerous references. It would be interesting to learn if anyone has successfully integrated a newer version of MKL or IPPL in Matlab, as opposed to an entirely different library which is naturally another story. My hope is that a simple in-place DLL replacement might provide important performance and stability benefits across Matlab, without requiring a single line of code to change.
Unfortunately, I can’t test this as I do not have an independent license to MKL / IPPL. And I would probably wouldn’t know how to test it properly anyway if I did have a license. But there are plenty of smart linear-algebra experts out there who might just pick up the glove (Mike Croucher comes to mind, for one).
I’ve offered the bait – now let’s see if anything interesting comes up in the net…
I’m not sure if I’m allowed to discuss this in an open forum, but I just tried it in the R2013b prerelease, and they seem to be using the latest MKL 11.0.2 and FFT 3.3.3 versions. IPP is unchanged though.
Oh and you’ll be happy to know that MATLAB has finally upgraded to Java 7 🙂
[…] Two weeks ago, I posted about Matlab’s math libraries and their various versions across Matlab releases […]