Re: cblas library abstraction

[Mo Zhou <lumin@debian.org>]

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.