[Python-Dev] A new JIT compiler for a faster CPython?

Nick Coghlan ncoghlan at gmail.com
Wed Jul 18 12:30:04 CEST 2012


On Wed, Jul 18, 2012 at 7:45 PM, Mark Shannon <mark at hotpy.org> wrote:
> The practice
> ------------
>
> If you want modest speedup for modest effort, then look at Cesare's WPython.
> Also take a look at Stefan Brunthaler's work on inline caching in an
> interpreter.
>
> If you want a larger speedup then you need to tackle most or all of the
> causes of
> execution overhead listed above.
> HotPy (version 2, a fork of CPython) aims to tackle all of these causes
> except
> the GC overhead. As far as I am aware, it is the only project that does so.

Indeed, there's a lot that could be done in the CPython compiler and
eval loop, and the bytecode design used to communicate between them.
Thanks for summarising that so clearly.

There are a couple of other compiler related patches that anyone
interested in optimisation of CPython should at least glance at:

- Dave Malcolm's patch that adds a Python level AST optimisation step
to the compiler (effectively trading slower compile times for faster
execution of the compiled bytecode)
(http://bugs.python.org/issue10399)
- Eugene Toder's patch to add an AST optimisation step to the compiler
chain (http://bugs.python.org/issue11549) (I've asked Eugene about
this patch more recently and his current thought is that subsequent
improvements to the peephole optimisation have rendered it less
valuable. However, the patch is still a potentially useful resource
for anyone investigating bytecode optimisation ideas)

Cheers,
Nick.

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


More information about the Python-Dev mailing list