On Thu, Aug 7, 2014 at 8:32 PM, Charles R Harris wrote:

Hi All,

It looks like numpy dot only uses BLAS if ATLAS is present, see numpy/core/setup.py. Has anyone done the mods needed to use OpenBLAS? What is the current status of using OpenBLAS with numpy?

NVM, the comments and "NO_ATLAS_INFO" are respectively wrong and deceptive. Ugh.

Also, I'm thinking of moving linalg/lapack_lite/blas_lite.c down into the core. Thoughts?

Chuck

numpy dot is using BLAS with OpenBLAS. Tested on Linux and Windows (see https://bitbucket.org/carlkl/mingw-w64-for-python/downloads) Regards Carl 2014-08-09 0:31 GMT+02:00 Sturla Molden :

Charles R Harris wrote:

...

It looks like numpy dot only uses BLAS if ATLAS is present, see numpy/core/setup.py. Has anyone done the mods needed to use OpenBLAS? What is the current status of using OpenBLAS with numpy?

I thought it also uses BLAS if MKL or Accerate Framework is present, but I am not sure about OpenBLAS, ACML or Cray libsci.

Sturla

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

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... Sturla