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 multithreaded 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 Python2.7.6. To install numpy, I've followed exactly the instructions previously posted to this list by Thomas Unterthiner. See http://numpydiscussion.10968.n7.nabble.com/numpyACMLsupportiskindofbr.... 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 numpy1.8.0 so that it successfully uses the desired ACML libraries. I can confirm this by `ldd sitepackages/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 offlist, but thought it might be worth it to document this onlist)
I don't remember ever running into problems while using ACML in my numpy installs. However I never ran the whole testsuite, 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 AMDspecific (Bulldozer and Piledriverspecific, 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 numpyintegration 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 20140224 20:58, Michael Hughes wrote:
Hello,
I'm trying to build numpy from source to use AMD's ACML for matrix multiplication (specifically the multithreaded 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 Python2.7.6. To install numpy, I've followed exactly the instructions previously posted to this list by Thomas Unterthiner. See http://numpydiscussion.10968.n7.nabble.com/numpyACMLsupportiskindofbr.... 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 numpy1.8.0 so that it successfully uses the desired ACML libraries. I can confirm this by `ldd sitepackages/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
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
participants (2)

Michael Hughes

Thomas Unterthiner