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