Kevin Kofler <kevin.kofler(a)chello.at> writes:
Dominik 'Rathann' Mierzejewski wrote:
> It also needs some patching, because each library has a different
> SONAME.
Symlinking
libblas.so.3 → libopenblas.so.0
liblapack.so.3 → libopenblas.so.0
is enough to get things linked against BLAS and/or LAPACK to pick up
OpenBLAS instead. A similar symlinking should work for the -devel package.
If the symlinks confuse ldconfig or cause some other issues, linker scripts
can be used instead.
You'll find Dominik was correct if you try it.
> I think atlas used to provide a drop-in replacement, but it was
abandoned
Ouch! Indeed, the current ATLAS packages provide only libsatlas and
libtatlas, no libblas or liblapack. This is a regression and should never
have been packaged that way. Now all the packages end up with the
unoptimized reference BLAS.
Various things have been changed to use openblas on x86 after some of us
agitated.
(In fact, I think I already noticed that when it
happened and complained loudly about it, but was ignored, as it seems.
Sigh!)
As far as I remember, there's good reason (apart from the previous
(FPC?) vote against it), like the atlas blas and lapack have to go
together.
That said, ATLAS should really go away, unless they add support for
runtime
CPU detection and the result matches or exceeds OpenBLAS performance.
It will exceed it on any relevant platform that openblas doesn't
support, but where OB doesn't do DYNAMIC_ARCH you still have the problem
of needing micro-architecture-specific packages (which seems to be
against policy, although atlas does it).
In its
current state (which has been the state since its inception), ATLAS is
really unsuitable for distribution packaging. They just do not care about
binary packages, at all.
I don't know whether that's true, but Fedora could at least improve the
situation by providing more than the -sse2 and -sse3 packages.
> on the premise that scientific codes are compiled specificlly for
their
> target clusters anyway
… which is of course not true for distribution packages!
I might note that, typically, people who insist on specific compilation
haven't made relevant measurements -- I know that's not true generally
-- e.g. the myths about MKL et al. Where reasonable, the computational
kernels that are sensitive to SIMD should be abstracted into libraries
like openblas, libxsmm, fftw, elpa, etc.
> and Intel's math library (MKL) doesn't provide a drop-in
replacement.
… which is entirely irrelevant.
It is the job of the distribution to ensure that software uses the most
efficient BLAS/LAPACK implementation available. Other distributions ship
symlinks ensuring that. The current packaging in Fedora is horrible.
I presume that means the most efficient free implementation. On avx512,
that's BLIS (+libxsmm), but MKL is still substantially faster.