[Cython] Comments on example code?
Dag Sverre Seljebotn
dagss at student.matnat.uio.no
Tue Nov 25 19:21:27 CET 2008
Gabriel Gellner wrote:
> But the only difference in the caller between the f2py version and this one
> is this file. So the speed difference must be from the function calls etc as
> you have said, but I don't understand how the overhead can be from the caller
> as the code for this is identical (and not compiled).
>
> the code is basically:
>
> for model.b1 in np.linspace(0, 2.6, 100):
> odeint(model, y0, t0)
>
> where model is defined in a separate file, in one case as a fortran
> object generated by f2py and in this case by cython.
Ah, right.
It's interesting (but not that surprising) to see that f2py does perform
better in this area, due to both the call to np.empty and that acquiring
the buffer from the NumPy array likely is slower than the NumPy-specific
stuff that f2py is doing.
But that Python snippet is likely going to use the majority of the time
no matter how things are done, so it doesn't matter much. I'm interested
to hear how much do you gain over pure Python in this case then --
probably not too much, perhaps 2-300%? (Moving the entire for-loop to
Cython would typically give you around 800% improvement).
Anyway, this is not likely to be an area where Cython is improved, so
there's nothing to do about it. I don't think it is a common usecase
either -- typically either one keep everything in Python, or one decide
that Python only is too slow, but then one doesn't want to only leverage
a small part of the speed increase that compiled code can give you...
Even if you move the for-loop into Cython or Fortran you don't have to
use vectorized calculations. Something like:
cython_apply_odeint(model, 0, 2.6, 100)
and then just code a very generic for-loop in Cython which calls odeint
and model, just to move the loop on the other side of the
Python/Cython-barrier.
Enough ranting though. Thanks for bringing this to my attention!
--
Dag Sverre
More information about the Cython-dev
mailing list