On 12 January 2016 at 08:44, Victor Stinner <victor.stinner@gmail.com> wrote:
I discussed this PEP on the #pypy IRC channel. I will try to summarize the discussion with comments on the PEP directly.
2016-01-08 22:31 GMT+01:00 Victor Stinner <victor.stinner@gmail.com>:
Add an API to add specialized functions with guards to functions, to support static optimizers respecting the Python semantic.
"respecting the Python semantics" is not 100% exact. In fact, my FAT Python makes suble changes on the "Python semantics". For example, loop unrolling can completly remove the call the range() function. If a debugger is executed instruction per instruction, the output is different on an unrolled loop, since the range() call was removed, and the loop copy is copied. I should maybe elaborate this point in the rationale, explain that a compromise must be found between the funny "in Python, everything is mutable" and performance. But remember that the whole thing (FAT Python, specialization, etc.) is developed outside CPython and is fully optional.
Changes =======
* Add two new methods to functions:
- ``specialize(code, guards: list)``: add specialized function with guard. `code` is a code object (ex: ``func2.__code__``) or any callable object (ex: ``len``). The specialization can be ignored if a guard already fails.
This method doesn't make sense at all in PyPy. The method is specific to CPython since it relies on guards which have a pure C API (see below). The PEP must be more explicit about that. IMHO it's perfectly fine that PyPy makes this method a no-op (the method exactly does nothing). It's already the case if a guard "always" fail in first_check().
Perhaps the specialisation call should also move to being a pure C API, only exposed through _testcapi for testing purposes? That would move both this and the dict versioning PEP into the same territory as the dynamic memory allocator PEP: low level C plumbing that enables interesting CPython specific extensions (like tracemalloc, in the dynamic allocator case) without committing other implementations to emulating features that aren't useful to them in any way. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia