First results of the JIT

Hi all,

Just a quick note to tell you that we are progressing on the JIT front. Here are the running times of the richards benchmark on my laptop:

• 8.18 seconds with CPython 2.5.2;
• 2.61 seconds with pypy-c-jit (3x faster than CPython);
• 1.04 seconds if you ignore the time spent making assembler (8x faster than CPython);
• 1.59 seconds on Psyco, for reference (5x faster that CPython).

Yes, as this table shows, we are spending 1.57 seconds in the JIT support code. That's too much -- even ridiculously so -- for anything but a long-running process. We are working on that :-)

If you want to build your own pypy-c-jit (for x86-32 only for now):

• you need a Subversion checkout of trunk;
• run pypy/translator/goal/translate.py with the -Ojit option;
• as usual, wait a long time (and be sure you have more than 1GB of RAM).

For now pypy-c-jit spews a lot of debugging output and there are a few known examples where it crashes. As we like to repeat, however, it's a complete JIT: apart from the crashes (the bugs are probably in the JIT support code), it supports the whole Python language from the start -- in the sense of doing correct things. Future work include Python-specific improvements by e.g. tweaking the data structures used to store Python objects so that they are more JIT-friendly.

EDIT: Oh yes, fijal reminds me that CPython 2.6 is 30% faster than CPython 2.5 on this benchmark (which is mostly my "fault", as I extracted a small part of PyPy and submitted it as a patch to CPython that works particularly well for examples like richards). It does not fundamentally change the fact that we are way faster though.

PyPy sprint in Düsseldorf, 6 Nov - 13 Nov

The next PyPy sprint will be held in the Computer Science department of Heinrich-Heine Universität Düsseldorf from the 6th to the 13th of November 2009. This is a fully public sprint, everyone is welcome to join us.

Topics and goals

At the sprint we intend to work on the JIT generator in PyPy and on applying it to PyPy Python interpreter.

The precise work that will be done is not fixed, as we don't know in which state the JIT will be in November. However, possible areas of work might include:

• tweaking the interpreter/objspace to be more JIT-friendly, e.g. instance implementation code, call code
• if there is interest starting non x86-32 JIT backends
• trying out existing software to find features where the optimizations of the JIT could be improved
• improving our benchmarking infrastructure

We will give special priority to topics that "non-core" people find interesting (as long as they are somehow JIT-related).

For an introduction of how our JIT-generation process works, please refer to our blog:

http://morepypy.blogspot.com/2009/03/jit-bit-of-look-inside.html

There is also a more dense academic paper about the subject:

http://codespeak.net/svn/pypy/extradoc/talk/icooolps2009/bolz-tracing-jit-final.pdf

Location

The sprint will take place in a seminar room of the computer science department. It is in the building 25.12 of the university campus. For travel instructions see

http://stups.cs.uni-duesseldorf.de/anreise/esbahn.php

Registration

If you'd like to come, please subscribe to the pypy-sprint mailing list and drop a note about your interests and post any questions. More organisational information will be send to that list. We'll keep a list of people which we'll update (which you can do so yourself if you have codespeak commit rights).