After spending a huge amount of time on building the ATLAS from the source code, I found that libopenblas and libatals in the OpenSUSE 13.1 repository. My questions are
Does that easy-install (without tuning on your own computer) "libatlas" in the repository really improve the computation performance?
Is OpenBLAS better than ATLAS or only better than the easy-install "libatlas" in the repository of a flavor of Linux? See For faster R use OpenBLAS instead: better than ATLAS, trivial to switch to on Ubuntu.
I followed this post Compiling Numpy with OpenBLAS but cannot find "numpy.core._dotblas" module. Morever I couldn't build Numpy with ATLAS and OpenBLAS at the same time.
Could someone post a .py file or bash code for doing the comparison between ATLAS and OpenBLAS? For example.
I built Numpy-1.9 with my own ATLAS, compiled OpenBLAS from the source code and installed the "libopenblaso" (OpenMP version) and "libopenblasp" (pthreads version) in the repository of OpenSUSE 13.1. How to configure the links and the libraries so that one can tell Numpy-1.9 to use OpenBLAS instead of ATLAS without rebuilding the Numpy-1.9 package.
Note: If you install "libatlas" in the repository, the ATLAS is not tuned for your computer and cannot the computation performance much. Therefore, I built and tuned the ATLAS first, then built Numpy with my own ATLAS. After that I tried to link OpenBLAS to Numpy but failed.
Many thanks in advance!
Thank you @Dmitry for the quick reply! But the questions are not solved...
$ sudo zypper in libopenblasp0
The following NEW package is going to be installed:
libopenblasp0
1 new package to install.
Overall download size: 3.0 MiB. After the operation, additional 30.3 MiB will be used.
Continue? [y/n/? shows all options] (y):
Retrieving package libopenblasp0-0.2.11-11.1.x86_64 (1/1), 3.0 MiB ( 30.3 MiB unpacked)
Retrieving: libopenblasp0-0.2.11-11.1.x86_64.rpm ...........................[done (2.1 MiB/s)]
(1/1) Installing: libopenblasp0-0.2.11-11.1 ............................................[done]
Additional rpm output:
/sbin/ldconfig: Can't link /usr/lib64//usr/local/atlas/lib/libtatlas.so to libopenblas.so.0
Q: Why is there a funny double slash "..64//usr.."?
$ /usr/sbin/update-alternatives --config libblas.so.3
Selection Path Priority Status
------------------------------------------------------------
0 /usr/local/atlas/lib/libtatlas.so 70 auto mode
1 /usr/lib64/blas/libblas.so.3 50 manual mode
2 /usr/lib64/libopenblasp.so.0 20 manual mode
3 /usr/local/atlas/lib/libcblas.a 50 manual mode
4 /usr/local/atlas/lib/libptcblas.a 60 manual mode
5 /usr/local/atlas/lib/libsatlas.so 65 manual mode
* 6 /usr/local/atlas/lib/libtatlas.so 70 manual mode
Q: Is this configuration fine, as some static libraries ".a" are linked?
Note: "libopenblasp.so.0" is linked automatically after "zypper in", whilst all "atlas" libraries are manually created by the command:
$ /usr/sbin/update-alternatives --install /usr/lib64/blas/libblas.so.3 libblas.so.3 /usr/local/atlas/lib/libxxxx.x <Integer>
You can switch between system BLAS and LAPACK implementations by using update-alternatives. For example:
/usr/sbin/update-alternatives --config libblas.so.3
http://en.opensuse.org/openSUSE:Science_Linear_algebra_libraries
I don't know about atlas packages, but we provide openblas with multiarch support. Math kernel includes all processor specific optimizations and set right variant dynamically. Note, there are 3 versions of openblas library: serial, pthreads and openmp version. You need to use pthreads or openmp.