On 08/15/2017 02:47 PM, Kevin Kofler wrote:
Please note that what I am proposing here is not the same as my proposal
from 3 years ago that was rejected. While I would not complain if my old
proposal were implemented, I am now suggesting a much simpler approach
(which was already hinted at in the last paragraph of my old proposal):
* drop the inefficient implementations reference (netlib) BLAS/LAPACK and
ATLAS (have OpenBLAS Obsolete them),
Why?
* use one-way symlinks or linker scripts to make everything linking or
linked to them pick up OpenBLAS instead. So libblas, liblapack and libsatlas
would just redirect to libopenblas,
This could be easier done just by linking to -lopenblas.
* I am not sure about libtatlas, ideally it should redirect to libopenblaso,
but libtatlas uses raw pthread wheres libopenblaso uses OpenMP, this may
make a difference (e.g., it will certainly cause problems if the client
program uses OpenMP itself). If libopenblaso does not work as a drop-in
libtatlas replacement, libopenblas would have to be used instead (and the
programs that really want libopenblaso would have to be rebuilt for it).
Actually, the problem is a bit bigger. The basic OpenBLAS library comes
in three variants:
- sequential (libopenblas)
- pthreads (libopenblasp)
- OpenMP (libopenblaso)
The problem is that you can't mix these. Now, I use a lot of BLAS/LAPACK
and sometimes even within OpenMP parallel regions. The only library I
would use is libopenblaso, because by doing so you get parallel
performance in sequential regions, but it doesn't parallellize when you
call a routine within a parallel region (otherwise you'll launch too
many threads and destroy your performance).
While the OpenMP version has a marginally larger overhead than the
pthreads one, it is the OpenMP version that should be default.
However, in addition to these three main flavors, the library *also*
comes in versions that support 64-bit indexing (the good old 4-byte vs
8-byte Fortran integer problem):
- libopenblas{,p,o} is the 32-bit integer one
- libopenblas{,p,o}64 is the 64-bit integer one - which has the same
symbol names as libopenblas{,p,o} !!
- libopenblas{,p,o}64_ is the 64-bit integer one with a _ suffix so you
can link the same application to the 32-bit version libopenblas{,p,o}
so it's not a simple question of libblas.so and liblapack.so
--
Susi Lehtola
Fedora Project Contributor
jussilehtola@xxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
