dot!=matrixmultiply bug when dotblas is present
Hi all,
I found something today a bit unpleasant: if you install numeric without any BLAS support, 'matrixmultiply is dot==True', so they are fully interchangeable. However, to my surprise, if you build numeric with the blas optimizations, they are NOT identical. The reason is a bug in Numeric.py. After defining dot, the code reads:
#This is obsolete, don't use in new code matrixmultiply = dot
and at the very end of the file, we have:
# try to import blas optimized dot, innerproduct and vdot, if available try: from dotblas import dot, innerproduct, vdot except ImportError: pass
Obviously this means that matrixmultiply is stuck with the _old_ definition of dot, and does not benefit from the blas optimizations. This is BAD, as for a 1024x1024 matrix the difference is staggering:
planck[Numeric]> pylab
In [1]: a=rand(1024,1024)
In [2]: b=rand(1024,1024)
In [3]: from IPython.genutils import timing
In [4]: timing 1,dot,a,b ------> timing(1,dot,a,b) Out[4]: 0.55591500000000005
In [5]: timing 1,matrixmultiply,a,b ------> timing(1,matrixmultiply,a,b) Out[5]: 68.142640999999998
In [6]: _/__ Out[6]: 122.57744619231356
Pretty significant difference...
The fix is trivial. In Numeric.py, at the very end of the file, this part:
# try to import blas optimized dot, innerproduct and vdot, if available try: from dotblas import dot, innerproduct, vdot except ImportError: pass
should read instead:
# try to import blas optimized dot, innerproduct and vdot, if available try: from dotblas import dot, innerproduct, vdot matrixmultiply = dot #### <<<--- NEW LINE except ImportError: pass
I just checked and the problem still exists in Numpy 23.4.
Cheers,
f
Fernando Perez Fernando.Perez@colorado.edu writes:
Hi all,
I found something today a bit unpleasant: if you install numeric without any BLAS support, 'matrixmultiply is dot==True', so they are fully interchangeable. However, to my surprise, if you build numeric with the blas optimizations, they are NOT identical.
Oops, my bad (I submitted the patch and while pretty much all the real coding was done by Richard Everson this is my oversight).
The reason is a bug in Numeric.py. After defining dot, the code reads:
#This is obsolete, don't use in new code matrixmultiply = dot
On the other hand, it gently nudges people to no longer use the obsoleted matrixmultiply ;)
In [4]: timing 1,dot,a,b ------> timing(1,dot,a,b) Out[4]: 0.55591500000000005
In [5]: timing 1,matrixmultiply,a,b ------> timing(1,matrixmultiply,a,b) Out[5]: 68.142640999999998
In [6]: _/__ Out[6]: 122.57744619231356
Pretty significant difference...
Yup, someone should incorporate optional atlas dot support into numarray if it hasn't happened already (won't be me, IIRC it took some convincing to get this into Numeric and I won't be using numarray for anything real in the near future).
cheers,
alex
Alexander Schmolck schrieb:
Fernando Perez Fernando.Perez@colorado.edu writes:
Hi all,
I found something today a bit unpleasant: if you install numeric without any BLAS support, 'matrixmultiply is dot==True', so they are fully interchangeable. However, to my surprise, if you build numeric with the blas optimizations, they are NOT identical.
Oops, my bad (I submitted the patch and while pretty much all the real coding was done by Richard Everson this is my oversight).
No prob. It's been fixed in Numeric 23.5, so no more worries.
Pretty significant difference...
Yup, someone should incorporate optional atlas dot support into numarray if it hasn't happened already (won't be me, IIRC it took some convincing to get this into Numeric and I won't be using numarray for anything real in the near future).
I'll leave that question to the numarray guys, I have no idea where it stands in terms of blas/atlas support. I certainly hope it has it or that this optimization can be brought in, as it makes a huge difference for the large array case.
Best,
f
On Oct 1, 2004, at 2:49 PM, Fernando Perez wrote:
Alexander Schmolck schrieb:
Pretty significant difference...
Yup, someone should incorporate optional atlas dot support into numarray if it hasn't happened already (won't be me, IIRC it took some convincing to get this into Numeric and I won't be using numarray for anything real in the near future).
I'll leave that question to the numarray guys, I have no idea where it stands in terms of blas/atlas support. I certainly hope it has it or that this optimization can be brought in, as it makes a huge difference for the large array case.
Best,
f
I'm not sure when it will get done, but we are working on the early stages of getting scipy working with numarray. You should see visible signs of that within a month (i.e., at least some parts of scipy working with numarray). It will probably take months to finish though.
Perry
participants (3)
-
Alexander Schmolck -
Fernando Perez -
Perry Greenfield