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 <rober...@gmail.com> wrote: > On Thu, May 31, 2012 at 7:04 AM, Dag Sverre Seljebotn > <d.s.seljeb...@astro.uio.no> wrote: >> [Discussion on numfo...@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 _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
