BLAS and LAPACK ABI questions (mostly OSX related)
NumPy seems to define BLAS and LAPACK functions with gfortran ABI: https://github.com/numpy/numpy/blob/master/numpy/linalg/umath_linalg.c.src#L... extern float FNAME(sdot)(int *n, float *sx, int *incx, float *sy, int *incy); What happens on OS X where Accelerate Framework uses f2c ABI? SciPy has C wrappers for Accelerate to deal with this. Should NumPy adopt those as well? And while we are at it, why are LAPACK subroutines declared to return int? I thought a Fortran subroutine should map to a void function in C. From the same file: extern int FNAME(dgesv)(int *n, int *nrhs, double a[], int *lda, int ipiv[], double b[], int *ldb, int *info); Sturla
Yeah, that's definitely not the right signature for sdot when linked
against the Accelerate framework.
But what's the purpose of those wrappers in _umath_linalg? The one for
sdot, for example, doesn't appear to be used internally, and it isn't
available from the python side. While scipy has all of those function
pointers accessible in scipy.linalg.blas (e.g.
scipy.linalg.blas.sdot._cpointer), those function pointers point to the
underlying blas function and expose the ABI differences between platforms,
leading to, for example the utter nightmare of using the scipy blas
function pointers from cython in a cross platform way:
https://gist.github.com/anonymous/6659007.
-Robert
On Sun, Jun 8, 2014 at 5:36 PM, Sturla Molden
NumPy seems to define BLAS and LAPACK functions with gfortran ABI:
https://github.com/numpy/numpy/blob/master/numpy/linalg/umath_linalg.c.src#L...
extern float FNAME(sdot)(int *n, float *sx, int *incx, float *sy, int *incy);
What happens on OS X where Accelerate Framework uses f2c ABI? SciPy has C wrappers for Accelerate to deal with this. Should NumPy adopt those as well?
And while we are at it, why are LAPACK subroutines declared to return int? I thought a Fortran subroutine should map to a void function in C. From the same file:
extern int FNAME(dgesv)(int *n, int *nrhs, double a[], int *lda, int ipiv[], double b[], int *ldb, int *info);
Sturla
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi,
On Mon, Jun 9, 2014 at 2:31 AM, Robert McGibbon
Yeah, that's definitely not the right signature for sdot when linked against the Accelerate framework.
But what's the purpose of those wrappers in _umath_linalg? The one for sdot, for example, doesn't appear to be used internally, and it isn't available from the python side. While scipy has all of those function pointers accessible in scipy.linalg.blas (e.g. scipy.linalg.blas.sdot._cpointer), those function pointers point to the underlying blas function and expose the ABI differences between platforms, leading to, for example the utter nightmare of using the scipy blas function pointers from cython in a cross platform way: https://gist.github.com/anonymous/6659007.
Is it possible this is related to: https://github.com/numpy/numpy/issues/4007 or even: https://github.com/numpy/numpy/issues/4776 ? Best, Matthew
#4776 is definitely a separate issue. #4007 could be related similar f2c
ABI issues, but I don't think so. The difference between the gfotran and
g77/f2c ABIs, to my knowledge, is that (1) fortran REAL (single precision
floating point) return values are actually returned as a c double, not a c
float. (2) when return values are complex, the function is actually
implemented with an ABI that looks like a c function with an extra
pass-by-reference argument at the front of the function where the return
value is placed.
Despite the differences in the handling of the return values, I don't think
there is any difference in how float32 parameters are passed *in*, so I'm
not sure that these issues are related to subroutines like SGEMV which is
presumably behind #4007.
-Robert
On Sun, Jun 8, 2014 at 8:33 PM, Matthew Brett
Hi,
Yeah, that's definitely not the right signature for sdot when linked against the Accelerate framework.
But what's the purpose of those wrappers in _umath_linalg? The one for sdot, for example, doesn't appear to be used internally, and it isn't available from the python side. While scipy has all of those function pointers accessible in scipy.linalg.blas (e.g. scipy.linalg.blas.sdot._cpointer), those function pointers point to the underlying blas function and expose
On Mon, Jun 9, 2014 at 2:31 AM, Robert McGibbon
wrote: the ABI differences between platforms, leading to, for example the utter nightmare of using the scipy blas function pointers from cython in a cross platform way: https://gist.github.com/anonymous/6659007.
Is it possible this is related to:
https://github.com/numpy/numpy/issues/4007
or even:
https://github.com/numpy/numpy/issues/4776
?
Best,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
But I can't reproduce #4007 on my machine, so I'm not totally sure.
-Robert
On Sun, Jun 8, 2014 at 9:07 PM, Robert McGibbon
#4776 is definitely a separate issue. #4007 could be related similar f2c ABI issues, but I don't think so. The difference between the gfotran and g77/f2c ABIs, to my knowledge, is that (1) fortran REAL (single precision floating point) return values are actually returned as a c double, not a c float. (2) when return values are complex, the function is actually implemented with an ABI that looks like a c function with an extra pass-by-reference argument at the front of the function where the return value is placed.
Despite the differences in the handling of the return values, I don't think there is any difference in how float32 parameters are passed *in*, so I'm not sure that these issues are related to subroutines like SGEMV which is presumably behind #4007.
-Robert
On Sun, Jun 8, 2014 at 8:33 PM, Matthew Brett
wrote: Hi,
On Mon, Jun 9, 2014 at 2:31 AM, Robert McGibbon
wrote: Yeah, that's definitely not the right signature for sdot when linked against the Accelerate framework.
But what's the purpose of those wrappers in _umath_linalg? The one for sdot, for example, doesn't appear to be used internally, and it isn't available from the python side. While scipy has all of those function pointers accessible in scipy.linalg.blas (e.g. scipy.linalg.blas.sdot._cpointer), those function pointers point to the underlying blas function and expose the ABI differences between platforms, leading to, for example the utter nightmare of using the scipy blas function pointers from cython in a cross platform way: https://gist.github.com/anonymous/6659007.
Is it possible this is related to:
https://github.com/numpy/numpy/issues/4007
or even:
https://github.com/numpy/numpy/issues/4776
?
Best,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
You may need to run the test code a few times to get the issue.
Okay, yeah, I can reproduce the #4007 issue now. Both with the 3.4 dmg from
python.org and the OSX wheel as well as 2.7 with numpy compiled from
source. I need to run the test [1] a couple times to get it.
But I think Sturla's observation about the _umath_linalg ABI issues is
separate.
-Robert
[1] https://github.com/numpy/numpy/issues/4007#issuecomment-27708193
On Sun, Jun 8, 2014 at 9:25 PM, Matthew Brett
On Mon, Jun 9, 2014 at 5:08 AM, Robert McGibbon
wrote: But I can't reproduce #4007 on my machine, so I'm not totally sure.
Are you using the current OSX wheel from pypi to install?
You may need to run the test code a few times to get the issue.
Cheers,
Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Matthew Brett
Is it possible this is related to:
Possibly, but it seems to be in _dotblas which uses cblas. NumPy has its own cblas.h. Perhaps it conflicts with Apple's? Apple's documentation says that cblas_sdot returns float, but knowing Apple this might not be accurate. OK, time to locate cblas.h on my MacBook...
or even:
No. This happens because Accelerate and GCD are not designed to be fork-safe. One can argue that this bug is actually in multiprocessing and not in NumPy or Accelerate, since BLAS is not a part of POSIX. Only POSIX functions are required to be fork safe. Python 3.4 has a fix for it by allowing spawn (fork+exec) to be used instead of fork. It will never be fixed on Python 2.7 unless someone backports multiprocessing from Python 3.4. BTW: GotoBLAS2 is also affected by this problem, not just Accelerate. MKL and Atlas are safe, and so is OpenBLAS from master at GitHub. Sturla
On 09/06/14 13:40, Sturla Molden wrote:
Possibly, but it seems to be in _dotblas which uses cblas. NumPy has its own cblas.h. Perhaps it conflicts with Apple's?
Apple's documentation says that cblas_sdot returns float, but knowing Apple this might not be accurate. OK, time to locate cblas.h on my MacBook...
Hm, no, the declarations of cblas_sdot seems to be the same. NumPy: float cblas_sdot(const int N, const float *X, const int incX, const float *Y, const int incY); Apple: float cblas_sdot(const int N, const float *X, const int incX, const float *Y, const int incY) __OSX_AVAILABLE_STARTING(__MAC_10_2,__IPHONE_4_0); Sturla
On 09/06/14 14:37, Sturla Molden wrote:
Hm, no, the declarations of cblas_sdot seems to be the same.
Oh, stupid me, matrix * vector ... Then it must be cblas_sgemv. But those are the same too. Anyway, Enthought Canopy (linked with MKL) is *NOT* affected
m = np.random.rand(200).astype(np.float32) s = np.random.rand(10000, 200).astype(np.float32) np.dot(s,m)
array([ 52.27999878, 55.47311401, 63.61336517, ..., 56.2276535 , 56.59591293, 55.27639008], dtype=float32) I see an Anaconda user reports Anaconda is affected, but Anaconda is linked with MKL as well (or used to be?) Sturla
2014-06-09 14:53 GMT+02:00 Sturla Molden
I see an Anaconda user reports Anaconda is affected, but Anaconda is linked with MKL as well (or used to be?)
Not necessarily. Only if you buy the MKL optimization package: https://store.continuum.io/cshop/mkl-optimizations/ There is time limited evaluation package though. -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel
The free windows conda packages are linked against MKL statically, similar
to C. Gohlke's packges.
My guess: the MKL optimization package supports multithreading and SVML,
the free packages only a serial interface to MKL.
Carl
2014-06-09 14:59 GMT+02:00 Olivier Grisel
2014-06-09 14:53 GMT+02:00 Sturla Molden
: I see an Anaconda user reports Anaconda is affected, but Anaconda is linked with MKL as well (or used to be?)
Not necessarily. Only if you buy the MKL optimization package:
https://store.continuum.io/cshop/mkl-optimizations/
There is time limited evaluation package though.
-- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
2014-06-09 15:51 GMT+02:00 Carl Kleffner
The free windows conda packages are linked against MKL statically, similar to C. Gohlke's packges.
My guess: the MKL optimization package supports multithreading and SVML, the free packages only a serial interface to MKL.
That would make sense, indeed. -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel
participants (5)
-
Carl Kleffner
-
Matthew Brett
-
Olivier Grisel
-
Robert McGibbon
-
Sturla Molden