Hi, Debian's default (generic, no optimization) Atlas is really SLOW, such that I can write a faster BLAS by simply following this guide:
https://github.com/flame/how-to-optimize-gemm Debian's reference BLAS (netlib) contains both BLAS and CBLAS API/ABI, which should be able to be linked against by numpy, and then we can make numpy use a high-performance BLAS backend by simply switching alternatives. Any user of a modern x84_64 CPU can easily find the giant performance gap between the default Atlas (generic code) and the default OpenBLAS (generic+optimized, runtime-dispatch). MKL would be even faster if the user doesn't mind installing non-free. I guess "cblas" is supposed to mean a backend with "cblas_*" API/ABI, and "blas" for "*_" (Fortran) API/ABI. If this is true, then at least MKL and openblas are expected to work well. As for numpy's linkage to libcblas.so ... I guess Sandro isn't aware of the fact that BLAS implementations such as OpenBLAS squashed both C and Fortran ABI into to a single shared object. And AFAIK only Atlas split the C ABI into an individual library libcblas.so . ❯❯❯ readelf -d /usr/lib/python3/dist-packages/numpy/linalg/lapack_lite.cpython-37m-x86_64-linux-gnu.so Dynamic section at offset 0x3db0 contains 28 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [liblapack.so.3] 0x0000000000000001 (NEEDED) Shared library: [libcblas.so.3] 0x0000000000000001 (NEEDED) Shared library: [libblas.so.3] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000c (INIT) 0x1000 ^^^ The linkage against libcblas.so.3 is exactly why numpy asks for libatlas3. Please file a bug against numpy (severity: important). On Wed, Jan 02, 2019 at 12:48:03PM +0100, Jörg-Volker Peetz wrote: > Hi, > > I've noted that the new versions of the NumPy packages are now depending on > libatlas3-base besides libblas3 | libblas.so.3 and liblapack3 | > liblapack.so.3. > According to the maintainer Sandro Tosi this is due to the need of a cblas > library. As far as I understand, also openblas, BLIS, and GNU GSL > (libgslcblas0) > provide a cblas API. Would it make sense to have extra package(s) or > "Provides" > in order to get rid of a dependency on a special/additional package like > libatlas3-base? > > Regards, > Jörg.
