problems building numpy with ACML blas/lapack

Hello,
I'm trying to build numpy from source to use AMD's ACML for matrix multiplication (specifically the multi-threaded versions gfortran64_mp). I'm able to successfully compile and use a working version of np.dot, but my resulting installation doesn't pass numpy's test suite, instead, I get a segfault. I'm hoping for some advice on what might be wrong...
I'm on Debian, with a fresh install of Python-2.7.6. To install numpy, I've followed exactly the instructions previously posted to this list by Thomas Unterthiner. See http://numpy-discussion.10968.n7.nabble.com/numpy-ACML-support-is-kind-of-br.... The only thing I've adjusted is to try to use the gfortran64_mp version of ACML instead of just gfortran64.
Using those instructions, I can compile numpy-1.8.0 so that it successfully uses the desired ACML libraries. I can confirm this by `ldd site-packages/numpy/core/_dotblas.so`, which shows that I'm linked to libacml_mp.so as desired. Furthermore, some quick timing tests indicate that for a 1000x1000 matrix X, calls to np.dot(X,X) have similar speeds as using custom C code that directly calls the ACML libraries. So, dot seems to work as desired.
However, when I run numpy.test(verbose=4), I find that I get a seg fault ``` test_einsum_sums_cfloat128 (test_einsum.TestEinSum) ... Segmentation fault ```
Any ideas what might be wrong? From my benchmark tests, ACML is way faster than MKL or other options on my system, so I'd really like to use it, but I don't trust this current install.
Thanks! - Mike

Hi!
(I was contacted about this off-list, but thought it might be worth it to document this on-list)
I don't remember ever running into problems while using ACML in my numpy installs. However I never ran the whole test-suite, and I never used np.einsum (or complex numbers) in my own code. All I can tell you is that while using numpy with ACML, I never ran into any weird segfaults.
For what it's worth: OpenBLAS has added a lot of AMD-specific (Bulldozer- and Piledriver-specific, to be exact) code after its 0.2.8 version, which made it slightly faster than ACML on my own machines (at least for dgemm, I remember some LAPACK calls were a tiny bit slower, but not so much that it bothered me). Since numpy-integration of OpenBLAS is significantly better than ACML, I don't bother with the latter anymore.
You can download the OpenBLAS 0.2.9rc1 -- which includes the Bulldozer/Piledriver code -- from https://github.com/xianyi/OpenBLAS/releases/tag/v0.2.9.rc1
Cheers
Thomas
On 2014-02-24 20:58, Michael Hughes wrote:
Hello,
I'm trying to build numpy from source to use AMD's ACML for matrix multiplication (specifically the multi-threaded versions gfortran64_mp). I'm able to successfully compile and use a working version of np.dot, but my resulting installation doesn't pass numpy's test suite, instead, I get a segfault. I'm hoping for some advice on what might be wrong...
I'm on Debian, with a fresh install of Python-2.7.6. To install numpy, I've followed exactly the instructions previously posted to this list by Thomas Unterthiner. See http://numpy-discussion.10968.n7.nabble.com/numpy-ACML-support-is-kind-of-br.... The only thing I've adjusted is to try to use the gfortran64_mp version of ACML instead of just gfortran64.
Using those instructions, I can compile numpy-1.8.0 so that it successfully uses the desired ACML libraries. I can confirm this by `ldd site-packages/numpy/core/_dotblas.so`, which shows that I'm linked to libacml_mp.so as desired. Furthermore, some quick timing tests indicate that for a 1000x1000 matrix X, calls to np.dot(X,X) have similar speeds as using custom C code that directly calls the ACML libraries. So, dot seems to work as desired.
However, when I run numpy.test(verbose=4), I find that I get a seg fault
test_einsum_sums_cfloat128 (test_einsum.TestEinSum) ... Segmentation fault
Any ideas what might be wrong? From my benchmark tests, ACML is way faster than MKL or other options on my system, so I'd really like to use it, but I don't trust this current install.
Thanks!
- Mike
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
participants (2)
-
Michael Hughes
-
Thomas Unterthiner