I don't know where to put this so I put it up top:

I think this talk about implementing caching went a bit overboard myself. Here's a performance ladder for you:

Alternative A) Focus on fast lookup; go from 100 ns function call to 5 ns function call

Alternative B) Focus on caching a 20 ns lookup, go from 100 ns overhead to 2 ns function call (*any* function call through a pointer has a tiny bit of overhead according to my benchmark)

Alternative C) Early binding at compile time ("cdef extern from ..."); essentially no overhead (if from the C standard library, the compiler might even inline it).

Now, is there a need for B)? If you're not happy with a 5 ns function call, won't you always then go to alternative C)? Who's going to say "I can't live with a 5 ns penalty, but 2 ns is OK, thank you so much for implementing function pointer caching"?

To me it seems much simpler to just focus on a fast lookup that will automatically be fast everywhere, than to keep chasing different cases that must be cached because the lookup is slow.

What we're trying to kill is that 100ns-200ns Python call.

I simply don't think caching function pointers will *ever* be needed, if the lookup can be done fast. And that seems like a so much simpler design.

(Or, perhaps if we actually JIT-compile the call site. But that's a bridge we cross when we get there...)

More follows:

On 05/17/2012 02:58 PM, Stefan Behnel wrote:
mark florisson, 17.05.2012 13:34:
I think it's a good idea to start by only supporting CyFunction to get it
working, then add another fallback for a function attribute, then take a
look at other things.


If it works well we can plunge ahead and generalize it for
arbitrary types. (I think in any case we only needed to change things
outside of Cython to standardize stuff across projects, not because we
technically need it).

Absolutely.

The whole reason I brought up this is because Numba and SciPy is going to need this to talk between themselves. And Travis has a hand in both of those. One semi-standard will happen there one way or the other, I just wanted it to be something that was really benefitial to Cython as well, and allows Cython to be a player here.

Obviously, a CyFunction is not what the manually written C code in SciPy is going to play along with.

And if that happens anyway, why care about CyFunction?

Dag
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel

Reply via email to