Pyrex - Numeric demo doesn't build in 0.7.2

Fernando Perez fperez528 at yahoo.com
Wed May 14 19:04:53 EDT 2003


Pedro Rodriguez wrote:


> Possible hints :
> 
> - do with 'sin' what you have done with 'exp' :
>   sin = math.sin # local lookup on symbol instead of global
> 
> - use math.h "sin" instead of python's one :
> 
>     from math import pi,sqrt
> 
>     cdef extern from "math.h":
>         cdef double sin(double x)

Thanks.  These give about a 30% improvement.  Here is a summary table with a
bunch of approaches:

Version         Time    To fast To Python
=========================================
Fortran          0.29    1.00   86.54
C++ std          0.48    1.65   52.41
C++ typedef      0.48    1.66   52.20
C++ all          0.49    1.69   51.17
C++ Euler        0.49    1.70   50.96
C++ exp          0.68    2.33   37.16
C/numpy exp      1.23    4.24   20.40
C/numpy Euler    1.31    4.50   19.24
Numeric exp      1.87    6.42   13.49
Numeric Euler    1.97    6.76   12.80
Pyrex           19.48   66.93    1.29
Python          25.18   86.54    1.00

Basically, things begin to get interesting by the time you rewrite the code in
C++, which has support for complex Numeric arrays via Blitz++.  Unfortunately,
std::complex is still rather brain-damaged, so for real speed,  you still need
this in Fortran.  Note that the Fortran version (F90) is still being called
from within python, thanks to the wonders of f2py.

While this is a micro-benchmark (grain of salt, blah...), it's still a useful
guide.  My approach these days is still to use C/C++ when I can (via
weave.inline), resorting to Fortran (via f2py) only if I have to.  Numeric may
be ok also in many non-critical areas.

Cheers,

f.




More information about the Python-list mailing list