Hi, Perhaps this is a too recurrent subject, but I'm having problems when making numarray to use ATLAS instead of the mini-lapack included. I've installed ATLAS 3.6.0 on my pentium IV machine. I've made it a completely featured LAPACK by following the instructions in: http://math-atlas.sourceforge.net/errata.html#completelp and I'm pretty sure that the resulting library works. Now, after exporting USE_LAPACK and set the appropiate directory for lapack_dirs in addons.py, the compilation went well (however, I can see that lapack_litemodule.c is still being compiled, and I don't know if that's normal or not). The command I've used to install is: $ python setup.py install --gencode --home=/users/exp/alted/bin-i686 And the error that happens during the test phase follows: $ python Python 2.3.4 (#1, Jul 22 2004, 20:47:54) [GCC 3.3.2 20031022 (Red Hat Linux 3.3.2-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import numarray.testall as testall testall.test() numarray: ((0, 1199), (0, 1199)) numarray.records: (0, 48) numarray.strings: (0, 176) numarray.memmap: (0, 82) numarray.objects: (0, 105) numarray.memorytest: (0, 16) numarray.examples.convolve: ((0, 20), (0, 20), (0, 20), (0, 20)) numarray.convolve: (0, 52) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/users/exp/alted/bin-i686/lib/python/numarray/testall.py", line 24, in test result = eval(p+".test()") File "<string>", line 0, in ? File "/users/exp/alted/bin-i686/lib/python/numarray/fft/FFT.py", line 326, in test import dtest File "/users/exp/alted/bin-i686/lib/python/numarray/fft/dtest.py", line 238, in ? import numarray.random_array as random_array File "/users/exp/alted/bin-i686/lib/python/numarray/random_array/__init__.py", line 7, in ? from RandomArray2 import * File "/users/exp/alted/bin-i686/lib/python/numarray/random_array/RandomArray2.py", line 3, in ? import numarray.linear_algebra as linalg File "/users/exp/alted/bin-i686/lib/python/numarray/linear_algebra/__init__.py", line 1, in ? from LinearAlgebra2 import * File "/users/exp/alted/bin-i686/lib/python/numarray/linear_algebra/LinearAlgebra2.py", line 23, in ? import lapack_lite2 ImportError: /users/exp/alted/bin-i686/lib/python/numarray/linear_algebra/lapack_lite2.so: undefined symbol: dgesdd_
I've checked that dgesdd symbol exists on my liblapack.a: $ strings ~/bin-i686/lib/atlas/liblapack.a | grep dgesdd dgesdd.o/ 1097832195 2514 515 100644 13788 ` but not a dgesdd_, as you can see. I'm missing something? -- Francesc Alted
Hi, Despite de fact that some errors arise, I've checked the numarray version linked against ATLAS, and it seems like it doesn't get the expected ATLAS boost:
import timeit t1 = timeit.Timer("m3=numarray.dot(m1,m2)", "import numarray;dim1=500;m1=numarray.arange(dim1*dim1,shape=(dim1,dim1), type=numarray.Float32);m2=numarray.arange(dim1*dim1,shape=(dim1,dim1), type=numarray.Float32)") t1.repeat(3,10) [3.7274820804595947, 3.8542821407318115, 3.7117569446563721]
However, Numeric seems to get it:
t3 = timeit.Timer("m3=Numeric.dot(m1,m2)", "import Numeric;dim1=500;m1=Numeric.arange(dim1*dim1, typecode='f');Numeric.reshape(m1, (dim1,dim1));m2=Numeric.arange(dim1*dim1,typecode='f');Numeric.reshape(m2,(dim1,dim1))") t3.repeat(3,10) [0.0093162059783935547, 0.0096318721771240234, 0.0092968940734863281]
i.e. almost 300 faster than numarray Anyone is getting the acceleration boost with numarray & ATLAS? Cheers, A Divendres 15 Octubre 2004 13:18, Francesc Alted va escriure:
Hi,
Perhaps this is a too recurrent subject, but I'm having problems when making numarray to use ATLAS instead of the mini-lapack included.
I've installed ATLAS 3.6.0 on my pentium IV machine. I've made it a completely featured LAPACK by following the instructions in:
http://math-atlas.sourceforge.net/errata.html#completelp
and I'm pretty sure that the resulting library works. Now, after exporting USE_LAPACK and set the appropiate directory for lapack_dirs in addons.py, the compilation went well (however, I can see that lapack_litemodule.c is still being compiled, and I don't know if that's normal or not). The command I've used to install is:
$ python setup.py install --gencode --home=/users/exp/alted/bin-i686
And the error that happens during the test phase follows:
$ python Python 2.3.4 (#1, Jul 22 2004, 20:47:54) [GCC 3.3.2 20031022 (Red Hat Linux 3.3.2-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import numarray.testall as testall testall.test() numarray: ((0, 1199), (0, 1199)) numarray.records: (0, 48) numarray.strings: (0, 176) numarray.memmap: (0, 82) numarray.objects: (0, 105) numarray.memorytest: (0, 16) numarray.examples.convolve: ((0, 20), (0, 20), (0, 20), (0, 20)) numarray.convolve: (0, 52) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/users/exp/alted/bin-i686/lib/python/numarray/testall.py", line 24, in test result = eval(p+".test()") File "<string>", line 0, in ? File "/users/exp/alted/bin-i686/lib/python/numarray/fft/FFT.py", line 326, in test import dtest File "/users/exp/alted/bin-i686/lib/python/numarray/fft/dtest.py", line 238, in ? import numarray.random_array as random_array File "/users/exp/alted/bin-i686/lib/python/numarray/random_array/__init__.py", line 7, in ? from RandomArray2 import * File "/users/exp/alted/bin-i686/lib/python/numarray/random_array/RandomArray2.py", line 3, in ? import numarray.linear_algebra as linalg File "/users/exp/alted/bin-i686/lib/python/numarray/linear_algebra/__init__.py", line 1, in ? from LinearAlgebra2 import * File "/users/exp/alted/bin-i686/lib/python/numarray/linear_algebra/LinearAlgebra2.py", line 23, in ? import lapack_lite2 ImportError: /users/exp/alted/bin-i686/lib/python/numarray/linear_algebra/lapack_lite2.so: undefined symbol: dgesdd_
I've checked that dgesdd symbol exists on my liblapack.a:
$ strings ~/bin-i686/lib/atlas/liblapack.a | grep dgesdd dgesdd.o/ 1097832195 2514 515 100644 13788 `
but not a dgesdd_, as you can see.
I'm missing something?
-- Francesc Alted
A Divendres 15 Octubre 2004 19:03, Francesc Alted va escriure:
import timeit t1 = timeit.Timer("m3=numarray.dot(m1,m2)", "import numarray;dim1=500;m1=numarray.arange(dim1*dim1,shape=(dim1,dim1), type=numarray.Float32);m2=numarray.arange(dim1*dim1,shape=(dim1,dim1), type=numarray.Float32)") t1.repeat(3,10) [3.7274820804595947, 3.8542821407318115, 3.7117569446563721]
However, Numeric seems to get it:
t3 = timeit.Timer("m3=Numeric.dot(m1,m2)", "import Numeric;dim1=500;m1=Numeric.arange(dim1*dim1, typecode='f');Numeric.reshape(m1, (dim1,dim1));m2=Numeric.arange(dim1*dim1,typecode='f');Numeric.reshape(m2,(dim1,dim1))") t3.repeat(3,10) [0.0093162059783935547, 0.0096318721771240234, 0.0092968940734863281]
i.e. almost 300 faster than numarray
Ooops! The Numeric test had a bug on it. The correct test would be:
t3 = timeit.Timer("m3=Numeric.dot(m1,m2)", "import Numeric;dim1=500;m1=Numeric.arange(dim1*dim1, typecode='f');m1=Numeric.reshape(m1, (dim1,dim1));m2=Numeric.arange(dim1*dim1,typecode='f');m2=Numeric.reshape(m2,(dim1,dim1))") t3.repeat(3,10) [0.47363090515136719, 0.47403502464294434, 0.47770595550537109]
which is 8 times faster, more or less, than numarray (or Numeric) without ATLAS. Just to clarify things ;) -- Francesc Alted
On Sat, 2004-10-16 at 07:27, Francesc Alted wrote:
A Divendres 15 Octubre 2004 19:03, Francesc Alted va escriure:
import timeit t1 = timeit.Timer("m3=numarray.dot(m1,m2)", "import numarray;dim1=500;m1=numarray.arange(dim1*dim1,shape=(dim1,dim1), type=numarray.Float32);m2=numarray.arange(dim1*dim1,shape=(dim1,dim1), type=numarray.Float32)") t1.repeat(3,10) [3.7274820804595947, 3.8542821407318115, 3.7117569446563721]
However, Numeric seems to get it:
t3 = timeit.Timer("m3=Numeric.dot(m1,m2)", "import Numeric;dim1=500;m1=Numeric.arange(dim1*dim1, typecode='f');Numeric.reshape(m1, (dim1,dim1));m2=Numeric.arange(dim1*dim1,typecode='f');Numeric.reshape(m2,(dim1,dim1))") t3.repeat(3,10) [0.0093162059783935547, 0.0096318721771240234, 0.0092968940734863281]
i.e. almost 300 faster than numarray
Ooops! The Numeric test had a bug on it. The correct test would be:
t3 = timeit.Timer("m3=Numeric.dot(m1,m2)", "import Numeric;dim1=500;m1=Numeric.arange(dim1*dim1, typecode='f');m1=Numeric.reshape(m1, (dim1,dim1));m2=Numeric.arange(dim1*dim1,typecode='f');m2=Numeric.reshape(m2,(dim1,dim1))") t3.repeat(3,10) [0.47363090515136719, 0.47403502464294434, 0.47770595550537109]
which is 8 times faster, more or less, than numarray (or Numeric) without ATLAS.
Just to clarify things ;)
Hi Francesc, I don't think numarray dot() will pick up any boost at all from ATLAS because it's not written to do it. Besides that, there are two performance problems I know of with numarray's dot() which may dominate or dilute any ATLAS benefits: 1. dot() requires array creation. 2. dot() requires array copies. Because it has a class hierarchy and a memory buffer object, numarray is at a disadvantage for (1). (2) just hasn't been optimized yet for noncontiguous arrays which (I think) are always present when dot() starts with two contiguous array parameters. Regards, Todd
Hi Todd, A Diumenge 17 Octubre 2004 03:50, Todd Miller va escriure:
I don't think numarray dot() will pick up any boost at all from ATLAS because it's not written to do it. Besides that, there are two performance problems I know of with numarray's dot() which may dominate or dilute any ATLAS benefits:
1. dot() requires array creation.
Yes, but my guess is that for large arrays, this time should be negligible compared with the multiplication time.
2. dot() requires array copies.
Mmm, you mean even for well-behaved arrays? Sorry, but I don't understand why. May I ask if there is any plan to complete a better integration of external LAPACK libraries in numarray or this is considered low priority? Never mind, I don't need this functionality right now. It's just that I'm preparing a series of 'hands-on' sessions about Python and Scientific Computing, and I was trying to understand the current advantages and limitations of numarray compared with NumPy. Cheers, -- Francesc Alted
On Mon, 2004-10-18 at 04:29, Francesc Alted wrote:
Hi Todd,
A Diumenge 17 Octubre 2004 03:50, Todd Miller va escriure:
I don't think numarray dot() will pick up any boost at all from ATLAS because it's not written to do it. Besides that, there are two performance problems I know of with numarray's dot() which may dominate or dilute any ATLAS benefits:
1. dot() requires array creation.
Yes, but my guess is that for large arrays, this time should be negligible compared with the multiplication time.
Probably true. I should measure this. For small computations, it's an issue.
2. dot() requires array copies.
Mmm, you mean even for well-behaved arrays? Sorry, but I don't understand why.
I looked at this some this morning, trying to figure out why this is a problem only for numarray. It turns out that Numeric strides its arrays to get around the copy. When I implemented numarray, I chose not to stride because I thought it would be too slow... Recently I realized that one input array to dot() is *always* transposed and therefore likely noncontiguous and therefore copied. I think it's now possible to simply port the Numeric code so I'll look into that.
May I ask if there is any plan to complete a better integration of external LAPACK libraries in numarray or this is considered low priority?
Perry may answer this. I have no immediate plans for it... it does sound like enough people need this that it should be done. Regards, Todd
On Oct 18, 2004, at 7:52 AM, Todd Miller wrote:
On Mon, 2004-10-18 at 04:29, Francesc Alted wrote:
May I ask if there is any plan to complete a better integration of external LAPACK libraries in numarray or this is considered low priority?
Perry may answer this. I have no immediate plans for it... it does sound like enough people need this that it should be done.
Like Todd says, it does sound like this needs to be done. I think it takes a back seat to doing the scipy integration in general, but will need to be addressed soon thereafter. Perry
A Dilluns 18 Octubre 2004 13:52, Todd Miller va escriure:
1. dot() requires array creation.
Yes, but my guess is that for large arrays, this time should be negligible compared with the multiplication time.
Probably true. I should measure this. For small computations, it's an issue.
Well, for small arrays ATLAS (or any other optimized LAPACK library) can't probably do much better than lapack lite, so I think you should not worry about this anyway.
Perry may answer this. I have no immediate plans for it... it does sound like enough people need this that it should be done.
Ok. Thanks for information, -- Francesc Alted
participants (3)
-
Francesc Alted -
Perry Greenfield -
Todd Miller