Hi All, I run Mac OS X 10.9.1 and was trying to get OpenBLAS working for numpy. I've downloaded the OpenBLAS source and compiled it (thanks to Olivier Grisel). I installed everything to /usr/local/lib (I believe): e.g. "ll /usr/local/lib/ | grep openblas" lrwxr-xr-x 1 37B 10 Feb 14:51 libopenblas.a@ -> libopenblas_sandybridgep-r0.2.9.rc1.a lrwxr-xr-x 1 56B 10 Feb 14:51 libopenblas.dylib@ -> /usr/local/lib/libopenblas_sandybridgep-r0.2.9.rc1.dylib -rw-r--r-- 1 18M 7 Feb 16:02 libopenblas_sandybridgep-r0.2.9.rc1.a -rwxr-xr-x 1 12M 10 Feb 14:51 libopenblas_sandybridgep-r0.2.9.rc1.dylib* Then I download the numpy sources and add a site.cfg with the only three lines uncommented being: [openblas] libraries = openblas library_dirs = /usr/local/lib include_dirs = /usr/local/include When I run python setup.py config I get message that say that openblas_info has been found. I then run setup build and setup install (into a virtualenv). In the virtualenv, when I then check what _dotblas.so is linked to, I keep getting that it is linked to Accelerate. E.g. otool -L .../numpy/core/_dotblas.so => /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate Any suggestions on getting my numpy working with OpenBLAS? Thanks, Jurgen
I have exactly the same setup as yours and it links to OpenBLAS correctly (in a venv as well, installed with python setup.py install). The only difference is that I installed OpenBLAS in the default folder: /opt/OpenBLAS (and I reflected that in site.cfg). When you run otool -L, is it in your source tree or do you point to the numpy/core/_dotblas.so of the site-packages folder of your venv? If you activate your venv, go to a different folder (e.g. /tmp) and type: python -c "import numpy as np; np.show_config()" what do you get? I get: $ python -c "import numpy as np; np.show_config()" lapack_opt_info: libraries = ['openblas', 'openblas'] library_dirs = ['/opt/OpenBLAS/lib'] language = f77 blas_opt_info: libraries = ['openblas', 'openblas'] library_dirs = ['/opt/OpenBLAS/lib'] language = f77 openblas_info: libraries = ['openblas', 'openblas'] library_dirs = ['/opt/OpenBLAS/lib'] language = f77 blas_mkl_info: NOT AVAILABLE -- Olivier
First thing I noticed when installing into /opt/OpenBLAS was that the LAPACK header files were not being copied properly. This was because the OpenBLAS makefile uses the "-D" option in the install command which the default Mac install doesn't support. A quick "brew install coreutils" solved that problem. I rebuilt a new virtualenv and rebuilt numpy into it using the OpenBLAS in /opt/OpenBLAS and things seem to be absolutely fine now. I can run the OpenBLAS version on my mac. Thanks for the suggestions! I ran the test: https://gist.githubusercontent.com/osdf/3842524/raw/df01f7fa9d849bec353d6ab0... On my Macbook Pro (Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz, 8GB Ram) disappointingly: the Atlas version gives consistent 0.02, the OpenBLAS version runs in 0.1 with OMP_NUM_THREADS=1 and 0.04 with OMP_NUM_THREADS=8. Happy to run a more extensive test suite if anyone is interested. Jurgen On Thu, Feb 20, 2014 at 6:07 PM, Olivier Grisel <olivier.grisel@ensta.org>wrote:
I have exactly the same setup as yours and it links to OpenBLAS correctly (in a venv as well, installed with python setup.py install). The only difference is that I installed OpenBLAS in the default folder: /opt/OpenBLAS (and I reflected that in site.cfg).
When you run otool -L, is it in your source tree or do you point to the numpy/core/_dotblas.so of the site-packages folder of your venv?
If you activate your venv, go to a different folder (e.g. /tmp) and type:
python -c "import numpy as np; np.show_config()"
what do you get? I get:
$ python -c "import numpy as np; np.show_config()" lapack_opt_info: libraries = ['openblas', 'openblas'] library_dirs = ['/opt/OpenBLAS/lib'] language = f77 blas_opt_info: libraries = ['openblas', 'openblas'] library_dirs = ['/opt/OpenBLAS/lib'] language = f77 openblas_info: libraries = ['openblas', 'openblas'] library_dirs = ['/opt/OpenBLAS/lib'] language = f77 blas_mkl_info: NOT AVAILABLE
-- Olivier _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Indeed I just ran the bench on my Mac and OSX Veclib is more than 2x faster than OpenBLAS on such squared matrix multiplication (I just have 2 physical cores on this box). MKL from Canopy Express is slightly slower OpenBLAS for this GEMM bench on that box. I really wonder why Veclib is faster in this case. Maybe OSX 10.9 did improve its perf...
On 20/02/14 17:57, Jurgen Van Gael wrote:
Hi All,
I run Mac OS X 10.9.1 and was trying to get OpenBLAS working for numpy. I've downloaded the OpenBLAS source and compiled it (thanks to Olivier Grisel).
How? $ make TARGET=SANDYBRIDGE USE_OPENMP=0 BINARY=64 NOFORTRAN=1 make: *** No targets specified and no makefile found. Stop. (staying with MKL...) Sturla
On Sat, Feb 22, 2014 at 8:55 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
On 20/02/14 17:57, Jurgen Van Gael wrote:
Hi All,
I run Mac OS X 10.9.1 and was trying to get OpenBLAS working for numpy. I've downloaded the OpenBLAS source and compiled it (thanks to Olivier Grisel).
How?
$ make TARGET=SANDYBRIDGE USE_OPENMP=0 BINARY=64 NOFORTRAN=1 make: *** No targets specified and no makefile found. Stop.
(staying with MKL...)
Without any further details about what you downloaded and where you executed this command, one can only assume PEBCAK. There is certainly a Makefile in the root directory of the OpenBLAS source: https://github.com/xianyi/OpenBLAS If you actually want some help, you will have to provide a *little* more detail. -- Robert Kern
On 22/02/14 22:00, Robert Kern wrote:
If you actually want some help, you will have to provide a *little* more detail.
$ git clone https://github.com/xianyi/OpenBLAS Oops... $ cd OpenBLAS did the trick. I need some coffee :) Sturla
On Sat, Feb 22, 2014 at 3:55 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
On 20/02/14 17:57, Jurgen Van Gael wrote:
Hi All,
I run Mac OS X 10.9.1 and was trying to get OpenBLAS working for numpy. I've downloaded the OpenBLAS source and compiled it (thanks to Olivier Grisel).
How?
$ make TARGET=SANDYBRIDGE USE_OPENMP=0 BINARY=64 NOFORTRAN=1
You'll definitely want to disable the affinity support too, and probably memory warmup. And possibly increase the maximum thread count, unless you'll only use the library on the computer it was built on. And maybe other things. The OpenBLAS build process has so many ways to accidentally impale yourself, it's an object lesson in why building regulations are a good thing. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
On 22/02/14 22:15, Nathaniel Smith wrote:
$ make TARGET=SANDYBRIDGE USE_OPENMP=0 BINARY=64 NOFORTRAN=1
You'll definitely want to disable the affinity support too, and probably memory warmup. And possibly increase the maximum thread count, unless you'll only use the library on the computer it was built on. And maybe other things. The OpenBLAS build process has so many ways to accidentally impale yourself, it's an object lesson in why building regulations are a good thing.
Thanks for the advice. Right now I am just testing on my own computer. cblas_dgemm is running roughly 50 % faster with OpenBLAS than MKL 11.1 update 2, sometimes OpenBLAS is twice as fast as MKL. WTF??? :-D Ok, next runner up is Accelerate. Let's see how it compares to OpenBLAS and MKL on Mavericks. Sturla
On 22/02/14 23:39, Sturla Molden wrote:
Ok, next runner up is Accelerate. Let's see how it compares to OpenBLAS and MKL on Mavericks.
It seems Accelerate has roughly the same performance as MKL now. Did the upgrade to Mavericks do this? These are the compile lines, in case you wonder: $ CC -O2 -o perftest_openblas -I/opt/OpenBLAS/include -L/opt/OpenBLAS/lib perftest_openblas.c -lopenblas $ CC -O2 -o perftest_accelerate perftest_accelerate.c -framework Accelerate $ source /opt/intel/composer_xe_2013/mkl/bin/mklvars.sh intel64 $ icc -O2 -o perftest_mkl -mkl -static-intel perftest_mkl.c Sturla
On 23/02/14 00:11, Sturla Molden wrote:
Did the upgrade to Mavericks do this?
Testing different matrix sizes and averaging 30 trials, they are quite similar, actually. Accelerate is perhaps the winner, but it really depends on the matrix size. See for yourself. :-) Sturla List of attachments: Plots of the average runtime: dgemm_test.png dgemm_test2.png C codes: perftest_openblas.c perftest_accelerate.c perftest_mkl.c Timings from my MacBook Pro (2.4 GHz i7) accelerate.txt openblas.txt mkl.txt
On 23/02/14 02:43, Sturla Molden wrote:>
Testing different matrix sizes and averaging 30 trials, they are quite similar, actually. Accelerate is perhaps the winner, but it really depends on the matrix size.
See for yourself.
Here is a plot of the relative runtime (using Accelerate as reference). Sturla
participants (5)
-
Jurgen Van Gael -
Nathaniel Smith -
Olivier Grisel -
Robert Kern -
Sturla Molden