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 <ar...@tunes.org> wrote: > Hi Richard, > > On 2 February 2015 at 17:56, Richard Plangger <r...@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@python.org > https://mail.python.org/mailman/listinfo/pypy-dev _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
