[Numpy-discussion] Numpy, BLAS, and CBLAS questions

[Pauli Virtanen]

13.07.2015, 20:08, Nathaniel Smith kirjoitti:
[clip]
> Keep in mind that any solution needs to support weird systems too,
> including Windows. I'm not sure we can assume that all BLAS libraries are
> ABI compatible either. Debian/Ubuntu make sure that this is true for the
> ones they ship, but not all systems are so carefully managed. For LAPACK in
> particular I'm pretty sure there are multiple ABIs in active use that scipy
> supports via code in numpy.distutils. (Hopefully someone with more
> expertise will speak up.)

On the ABI issue: there are two ABI issues to solve:

1. BLAS/LAPACK ABI <--> Fortran compiler ABI

2. Fortran compiler ABI <--> C

Issue 1 is simple for users who have configured their compiler
environment so that the fortran/BLAS/LAPACK chain is all ABI compatible;
ACML and MKL provide variants for different Fortran compilers. However,
on OSX the available Fortran compiler usually (gfortran) is not ABI
compatible with the system BLAS/LAPACK (Accelerate).

Issue 1+2 is something that is solved by the likes of CBLAS/LAPACKE.

Assuming an user who has properly configured
Fortran/BLAS/LAPACK/CBLAS/LAPACKE environment, the ABI issues are not a
problem that we would need to care about. However, especially on OSX,
providing a painless out-of-the-box experience is in conflict with this
assumption.

    ***

Examples of Fortran ABIs in the different libraries:

Eigen seems to assume gfortran ABI, not sure.
OSX Accelerate always uses g77 ABI (modulo bugs).
OpenBLAS can be either AFAIK depending on its configuration.
MKL provides several ABI variants for different compilers, with
different library names.
ACML seems to do so too.

Both BLAS and LAPACK have functions whose proper call convention in the
Fortran interface varies in g77 vs. gfortran. The part that doesn't vary
is often considered (eg. by f2py and many others) safe to call directly
from C modulo name mangling, although nothing strictly speaking
guarantees this.

Numpy assumes Fortran ABI -> C compatibility is handled by CBLAS. Numpy
only uses LAPACK functions with "safe" calling conventions, so LAPACKE
is not really required.

If CBLAS/LAPACKE are not used, then you have to implement it yourself.
(i) One option is to rely on a Fortran compiler, assume it is ABI
compatible with the target BLAS/LAPACK (not necessarily true on OSX),
and then connect to C either relying on the "safe" calling conventions
or Fortran2003 features. (ii) Alternatively, you can detect which
BLAS/LAPACK ABI variant is active, and select a suitable C shim.

Scipy uses a combination of both approaches, using a shim layer for the
"problematic functions" in all code (C and Fortran). The shim is
configured based on which BLAS seems to be active at compile time. If
none of the recognized special cases (eg. OSX Accelerate) apply, then it
is assumed the Fortran ABI provided by the selected LAPACK/BLAS is
compatible with the selected Fortran compiler. (Communication to Fortran
is done via the "safe" calling convention subset.)