[Cython] [Python-Dev] C-level duck typing
Dag Sverre Seljebotn
d.s.seljebotn at astro.uio.no
Thu May 17 19:55:21 CEST 2012
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...)
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).
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?
More information about the cython-devel