[Python-ideas] RFC: PEP: Specialized functions with guards

[Nick Coghlan]

On 12 January 2016 at 08:44, Victor Stinner <victor.stinner at 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 at 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 at gmail.com   |   Brisbane, Australia