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 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
