[pypy-dev] PyPy improving generated machine code

[Maciej Fijalkowski]

Hi

One topic that captured my interest is a light-weight type-specilizing
JIT that does not emit any assembler, but instead rewrites the
bytecode into a more type-specific form. This has been done before in
luajit and gives good results there. I wonder if the same can be
applied in PyPy

PS. Feel free to pop in to IRC #pypy on freenode, I can explain in
more detail what I mean

Cheers,
fijal

On Tue, Feb 3, 2015 at 1:54 PM, Armin Rigo <arigo at tunes.org> wrote:
> 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.
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev