[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


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:

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: