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?
