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