[Python-ideas] PEP 511: API for code transformers

Nick Coghlan ncoghlan at gmail.com
Sat Jan 16 22:59:56 EST 2016


On 17 January 2016 at 02:56, Kevin Conway <kevinjacobconway at gmail.com> wrote:
> I'm a big fan of your motivation to build an optimizer for cPython code.
> What I'm struggling with is understanding why this requires a PEP and
> language modification. There are already several projects that manipulate
> the AST for performance gains such as [1] or even my own ham fisted attempt
> [2].
>
> Would you please elaborate on why these external approaches fail and how
> language modifications would make your approach successful.

Existing external optimizers (include Victor's own astoptimizer, the
venerable psyco, static compilers like Cython, and dynamic compilers
like Numba) make simplifying assumptions that technically break some
of Python's expected runtime semantics. They get away with that by
relying on the assumption that people will only apply them in
situations where the semantic differences don't matter.

That's not good enough for optimization passes that are enabled
globally: those need to be semantics *preserving*, so they can be
applied blindly to any piece of Python code, with the worst possible
outcome being "the optimization was automatically bypassed or disabled
at runtime due to its prerequisites no longer being met".

The PyPy JIT actually works in much the same way, it just does it
dynamically at runtime by tracing frequently run execution paths. This
is both a strength (it allows even more optimal code generation based
on the actual running application), and a weakness (it requires time
for the JIT to warm up by identifying critical execution paths,
tracing them, and substituting the optimised code)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list