[pypy-dev] PyPy improving generated machine code

[Armin Rigo]

Hi Richard,

On 2 February 2015 at 17:56, Richard Plangger <rich at pasra.at> wrote:
> Sorry to bother again. I did not get any response yet. The problem is
> that I need a better picture about a topic I could work on for my thesis
> and I really would like to contribute to pypy. In this week I would like
> to decide what I'm aiming for (otherwise things might get shifted).
>
> It would be nice to have the information you mentioned earlier in your
> email about the method-JIT-like approach and others

Our general topic list is here:
http://pypy.readthedocs.org/en/latest/project-ideas.html

Others than me should chime in too, because I'm not the best person to
recommend what should be worked on in general.  Myself, I am
particularly interested in the STM work, where there is certainly
something to do, although it's a bit hard to plan in advance: it's
mostly of the kind: run stuff with pypy-stm, find conflicts, figure
out which ones are not inherent to the application but are simply
limitations of the interpreter, and then think about ways to avoid
them.

About the method JIT, we have only vague ideas.  I can't give any
estimate of how much work it will be, as it depends a lot on
details of the approach, like how much of the existing
infrastructure can be reused and how much must be redone from
scratch.

To be clear, we don't even have any clear indication that it
would be a good idea.  It seems to require more
interpreter-specific hints (say for PyPy's Python interpreter) to
drive the process, in order to control where it should stop
inlining and start emitting calls to the existing functions.

The prior work gives mixed results: if you consider for example
Jython running on a method-JIT-based Java, it would be
similar (minus possible hints we can add), but Jython is not
faster than CPython.  On the other hand, untyped Cython is
usually faster than CPython, but it benefits from gcc's slow
optimizations.  I would classify it as very much a research
project.


A bientôt,

Armin.