[Cython] SEP 201 draft: Native callable objects

[Robert Bradshaw]

On this note, a global string interning mechanism is likely to be of
interest beyond just native callable objects, so could be worth
separating out into a separate spec.

On Thu, May 31, 2012 at 11:50 AM, Robert Bradshaw <robertwb at gmail.com> wrote:
> On Thu, May 31, 2012 at 7:04 AM, Dag Sverre Seljebotn
> <d.s.seljebotn at astro.uio.no> wrote:
>> [Discussion on numfocus at googlegroups.com please]
>>
>> I've uploaded a draft-state SEP 201 (previously CEP 1000):
>>
>> https://github.com/numfocus/sep/blob/master/sep201.rst
>>
>> """
>> Many callable objects are simply wrappers around native code. This holds for
>> any Cython function, f2py functions, manually written CPython extensions,
>> Numba, etc.
>>
>> Obviously, when native code calls other native code, it would be nice to
>> skip the significant cost of boxing and unboxing all the arguments.
>> """
>>
>>
>> The thread about this on the Cython list is almost endless:
>>
>> http://thread.gmane.org/gmane.comp.python.cython.devel/13416/focus=13443
>>
>> There was a long discussion on the key-comparison vs. interned-string
>> approach. I've written both up in SEP 201 since it was the major point of
>> contention. There was some benchmarks starting here:
>>
>> http://thread.gmane.org/gmane.comp.python.cython.devel/13416/focus=13443
>>
>> And why provide a table and not a get_function_pointer starting here:
>>
>> http://thread.gmane.org/gmane.comp.python.cython.devel/13416/focus=13443
>>
>> For those who followed that and don't want to read the entire spec, the
>> aspect of flags is new. How do we avoid to duplicate entries/check against
>> two signatures for cases like a GIL-holding caller wanting to call a nogil
>> function? My take: For key-comparison you can compare under a mask, for
>> interned-string we should have additional flags field.
>>
>> The situation is a bit awkward: The Cython list consensus (well, me and
>> Robert Bradshaw) decided on what is "Approach 1" (key-comparison) in SEP
>> 201. I pushed for that.
>>
>> Still, now that a month has passed, I just think key-comparison is too ugly,
>> and that the interning mechanism shouldn't be *that* hard to code up,
>> probably 500 lines of C code if one just requires the GIL in a first
>> iteration, and that keeping the spec simpler is more important.
>>
>> So I'm tentatively proposing Approach 2.
>
> I'm still not convinced that a hybrid approach, where signatures below
> some cutoff are compiled down to keys, is not a worthwhile approach.
> This gets around variable-length keys (both the complexity and
> possible runtime costs for long keys) and allows simple libraries to
> produce and consume fast callables without participating in the
> interning mechanism.
>
> It's unclear how to rendezvous on a common interning interface without
> the GIL/Python, so perhaps requiring the GIL to use it not to onerous.
> An alternative is to acquire the GIL in the first/reference
> implementation (which could allow the interning function pointers to
> be cached by an external GIL-oblivions JIT for example). Presumably
> some other locking mechanism would be required if the GIL is not used,
> so the overhead would likely not be that great.
>
> - Robert