[PYTHON MATRIX-SIG] NumPy benchmarks

[Paul Barrett]

Greetings,

I've been doing some benchmarks of the fundamental array operations,
e.g. '+', '*', 'cos', 'log', etc., and making comparisons to C code
and IDL (RSI's Interactive Data Language).  I thought it would be
useful to have some numbers to show people.

The results on a SPARCstation 20 with 64 MB RAM are in MFIPS (millions
of floating-pointing instructions per second) where the array type is
Float32 and lengths are in millions of elements.  Hence, higher numbers
are better.

Addition and multiplication operations:

Length		C	IDL	Python
 0.1		6.67	6.67	5.00
 0.3		4.45	4.85	3.41
 1.0		4.52	4.86	3.26
 3.0		4.55	4.87	3.02
 5.0		0.72	0.36	0.51

Cosine operation:

Length		C	IDL	Python
 0.1		0.51	0.51	0.53
 0.3		0.57	0.50	0.52
 1.0		0.57	0.50	0.52
 3.0		0.20	0.13	0.19
 5.0		0.15	0.09	0.15

Tangent operation:

Length		C	IDL	Python
 1.0		0.38	0.44	0.35

Logarithm operation:

Length		C	IDL	Python
 1.0		0.75	0.70	0.65


1) As the numbers indicate, the binary operations show room for
improvement.  They are about 33% slower than the C and IDL code.  The
unary operations are typically within 10% and therefore are
satisfactory.  Does anyone have any suggestions about how the binary
ops can be improved?

2) Also note that the numbers become worse as the arrays become a
sizeable fraction of the computer's RAM size.  The addition of two
arrays in a third array of 5 million elements each requires 60 MB of
out of 64 MB of RAM.  Thus the results become dependant on the time
needed to swap memory.  At present, it's not clear to me if
improvements can be made in this area, but it would be a nice feather
in Python's cap if improvements could be made for very large arrays.

3) Having had sometime to work with NumPy recently, I have three
comments about the implementation:

The first is the use of 'arccos', 'arcsin', etc. instead of using
'acos', 'asin', etc.  This seems to me to be both inconsistent with
Python's math module which uses 'acos', 'asin', etc. and with common
practice.  Is there a reason for this?

The second is about the 'arrayrange' method.  It is very slow for very
large arrays.  During my initial tests, I found Python to be very slow
compared to C and IDL.  I then discovered the reason to be my use of
arrayrange to create arrays.  As the source code notes, this method
should be converted to C, since it can be used heavily in some
numerical algorithms.

And the third is the difference between umathmodule.c and
fast_umathmodule.c.  Currently there is none.  Will someone please
outline what they should be?

Cheers,
Paul

|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Paul Barrett  -  Astrophysicist  -  Universities Space Research Association |
|                 Compton Observatory Science Support Center                  |
| NASA/Goddard SFC     phone: 301-286-1108           "Cracking toast, Gromit" |
| Code 660.1,          FAX:   301-286-1681            says Wallace.           |
| Greenbelt,MD 20771   barrett@compass.gsfc.nasa.gov  (in The Wrong Trousers) |
|             http://lheawww.gsfc.nasa.gov/users/barrett/CV.html              |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================