[Cython] [Python-Dev] C-level duck typing

[Dag Sverre Seljebotn]

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