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.

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 :-)

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.

Thursday, September 24, 2009

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:

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).

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:

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).