Pyrex - Numeric demo doesn't build in 0.7.2
Pedro Rodriguez
pedro_rodriguez at club-internet.fr
Thu May 15 02:12:41 EDT 2003
On Thu, 15 May 2003 01:04:53 +0200, Fernando Perez wrote:
> 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.
>
I tried rewrite the core expression of the loop using a Pyrex binding to
Python's Py_complex implementation
cdef extern from "Python.h":
ctypedef struct Py_complex:
double real
double imag
cdef Py_complex cmul "_Py_c_prod" (Py_complex left, Py_complex right)
cdef Py_complex cexp "_Py_c_pow" (Py_complex num, Py_complex exp)
cdef object ccomplex "PyComplex_FromDoubles" (double real, double imag)
to notice that what takes time with Pyrex (and Python)
seems to be:
- the 'exp' operator on complex
- going from 'C' types to Python types
If you had access to 'C' (not C++) library, I would suggest to do a binding
around that library and write Pyrex code. But I think this will be insufficient
or at least not very readable, because you'll need to rewrite an expression like
'x * y' as 'cmul(x, y)' to prevent casting back and forth to Python's types.
--
Pedro
More information about the Python-list
mailing list