MBF: don't build against libatlas3-base if possible
Type: performance improvement, integration
Affected: `apt rdepends libatlas3-base`
Severity: important
BLAS is a basic dense linear algebra library, so important like
an mathematical "libc". The standard fortran implementation
is included in src:lapack, which is often *hundreds* times slower
than an optimized implementation.
When some maintainers are looking for the libcblas.so provider,
they may use libatlas3-base (/-dev) to build their package because
this is the only provider in the archive. That libcblas.so provided
by libatlas3-base is quite slow in terms of performance if not
re-compiled locally.
However, we science team maintainers have already merged the fortran
ABI (typically called BLAS) and the C ABI (typically called CBLAS)
into a single shared object: libblas.so.3
https://wiki.debian.org/DebianScience/LinearAlgebraLibraries
which is a update-alternative switchable backend library. Ideally
any program that needs BLAS/CBLAS ABIs should link against
libblas.so.3 instead of libcblas.so.3 (note the char "c" in middle)
Numpy had ever fallen into this "libatlas3-base" trap again and again:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779243
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913567
Currently we have these BLAS/CBLAS providers, sorted by
update-alternative priority (at the same time recommendation level):
100 openblas (pthread) # generally fastest
95 openblas (openmp)
90 openblas (serial)
80 blis (openmp) # nearly as fast as openblas
75 blis (pthread) # priority values will be updated in the next upload
70 blis (serial)
35 atlas3-base (?) # slow without local re-compilation
10 libblas3 (standard impl) # turtle
1 intel-mkl (fastest CPU impl on amd64, but non-free)
-100 libnvblas (CUDA impl, faster than mkl, but non-free nvidia cruft)
(some of these packages are still in new)
So packages should avoid directly linking against libcblas.so as
symbols are also provided by libblas.so . And linking against
libblas.so would enable a performance boost at the user's choice
or solutions for mitigating threading trouble.
@Sébastien, should we remove libcblas.so from atlas binary package,
to avoid new packages falling into the same trap?
@Andreas, can we add this point to science-team policy?
Reply to: