[Numpy-discussion] OpenBLAS and dotblas

Sturla Molden sturla.molden at gmail.com
Sat Aug 9 17:48:20 EDT 2014

On 09/08/14 16:28, Charles R Harris wrote:

> Yeah, I figured that out, there is a comment in dotblas that says not,
> but checking how things are configured, it turns out they should be
> good. The original problem seems to have been that dotblas requires
> cblas and can't work with fortran blas. OTOH, linalg uses the f2c
> interface and, I presume, can link to fortran libraries. It would be
> nice to unify the two at some point.

Right. At least ACML does not implement cblas, so I guess this one is 
not used then.

Does anyone have a comprehensive list of which BLAS libraries are 
actually used for _dotblas?

What is used for numpy.linalg I also don't know. Ideally we should use 
BLAS and LAPACK if it is present. (I think it does, but I am not sure.)

Then there is the issue of C vs. Fortran order input: _dotblas can 
handle this correctly, but I don't think numpy.linalg is fast for C 
ordered arrays. But it is often possible to avoid this algorithmically. 
E.g. call LQ instead of QR if numpy.linalg.qr is invoked with C arrays.
(There is little hope of optimizing scipy.linalg this way because of 
f2py, but numpy.linalg is easier to fix.)

And then there is the GIL. Should numpy.linalg release it? Why or why 
not? Usually we can assume BLAS and LAPACK to be thread-safe, but it 
depends on the Fortran compiler. (I am not sure about f2c'd lapack_lite 
and blas_lite, though. f2c is famous for generating code that is not 
re-entrant.) _dotblas just assumes the BLAS is reentrant, even though it 
might not be. But we could also just specify that NumPy requires a 
re-entrant BLAS and LAPACK, and those that don't have one are self to 
blame for any trouble caused by multithreading.

As for Fortran BLAS:

Accelerate does not officially support Fortran BLAS or Fortran LAPACK, 
but there are wrappers for it in SciPy. If I remember correctly it has 
CLAPACK (not LAPACKE) with f2c ABI.

It seems there are quite few things that need fixing or improvement...


More information about the NumPy-Discussion mailing list