Tuesday, June 16, 2009

News from the jit front

As usual, progress is going slower then predicted,
but nevertheless, we're working hard to make some progress.

We recently managed to make our nice GCs cooperate with our JIT. This is
one point from our detailed plan. As of now, we have a JIT with GCs and
no optimizations. It already speeds up some things, while slowing down
others. The main reason for this is that the JIT generates assembler which is kind
of ok, but it does not do the same level of optimizations gcc would do.

So the current status of the JIT is that it can produce assembler out
of executed python code (or any interpreter written in RPython actually),
but the results are not high quality enough since we're missing optimizations.

The current plan, as of now, looks as follows:

Improve the handling of GCs in JIT with inlining of malloc-fast
paths, that should speed up things by a constant, not too big factor.

Write a simplified python interpreter, which will be a base for experiments
and to make sure that our JIT does correct things with regard to
optimizations. That would work as mid-level integration test.

Think about ways to inline loop-less python functions into their parent's loop.

Get rid of frame overhead (by virtualizables)

Measure, write benchmarks, publish

Profit

Cheers,
fijal

As usual, progress is going slower then predicted,
but nevertheless, we're working hard to make some progress.

We recently managed to make our nice GCs cooperate with our JIT. This is
one point from our detailed plan. As of now, we have a JIT with GCs and
no optimizations. It already speeds up some things, while slowing down
others. The main reason for this is that the JIT generates assembler which is kind
of ok, but it does not do the same level of optimizations gcc would do.

So the current status of the JIT is that it can produce assembler out
of executed python code (or any interpreter written in RPython actually),
but the results are not high quality enough since we're missing optimizations.

The current plan, as of now, looks as follows:

Improve the handling of GCs in JIT with inlining of malloc-fast
paths, that should speed up things by a constant, not too big factor.

Write a simplified python interpreter, which will be a base for experiments
and to make sure that our JIT does correct things with regard to
optimizations. That would work as mid-level integration test.

Think about ways to inline loop-less python functions into their parent's loop.

How this plan relates: it does not. Fijal's style is to give the current idea of the plans. Don't believe him too much :-) This and April's plan need somehow to be added to each other, or something :-)

Unladen-Swallow's LLVM JIT is a very different beast: it compiles each Python function as a unit. You can only get a uniform bit of speedup this way (maybe 2-3x). By contrast, what we are doing gives a non-uniform speedup: like Psyco, we will probably obtain speedups between 2x and 100x depending on the use case.

- Improve the handling of GCs in JIT with inlining of malloc-fast paths, that should speed up things by a constant, not too big factor.- Measure, write benchmarks- Write a simplified python interpreter, which will be a base for experiments and to make sure that our JIT does correct things with regard to optimizations. That would work as mid-level integration test.- Think about ways to inline loop-less python functions into their parent's loop.- Measure, publish benchmarks, RELEASE 1.2- Get rid of frame overhead (by virtualizables)- Measure, publish benchmarks- Iterate...

Concerning current ideas vs April's roadmap: I understand that plans change and that's ok of course. But as April's roadmap isn't mentioned at all, I have no idea how the current ideas relate to the previous roadmap (like the current ideas replace the old road map or parts of it / they are additional ideas and the old roadmap is postponed / they are a detailing of (parts of) April's roadmap). Maybe that's obvious to people with better pypy-knowledge than me. I understand Armin's comment that they are additional ideas.