[pypy-dev] PyPy + LLVM

Armin Rigo arigo at tunes.org
Sun Mar 18 13:26:37 CET 2007


Hi Chris,

On Sat, Mar 17, 2007 at 03:25:26PM -0800, Chris Lattner wrote:
> My talk (available here 
> http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.html ) clearly doesn't 
> describe pypy as it exists today, but I think it describes a place that 
> pypy could get to if the community desired it (In other words, I think 
> the strengths of pypy and of its community both play well into this).

This is a FAQ (or I should say a CEPW - Common External Point of View):

http://codespeak.net/pypy/dist/pypy/doc/faq.html#can-pypy-compile-normal-python-programs

I agree that what you describe could be done, given enough efforts; it
may even be that the overall effort would be less than what we alredy
invested in PyPy.  However, I can't speak for all the people involved
with PyPy but I, at least, am not interested in this approach.  My own
vision is that of non-static, language-independent optimizations.  What
we are building supports arbitrary changes to the language semantics.

For now, changing the semantics is a static process which requires a
full rebuild of PyPy and its JIT, which takes about one hour.  In the
very long term it might be possible to allow such changes to be inserted
into a running environment - and to do that, LLVM will most likely be an
essential tool.

> Has python even been executed with a sustained performance of two 
> instructions per add? :)

Psyco did that for years, yes.  A few days ago, PyPy's own JIT did it
for trivial examples too.  Neither contain a type inference engine.  The
latter adapts automatically to arbitrary semantic changes.  Neither
produce optimal register usage: they produce code that requires
continuous run-time updates; at the hot spots, the code eventually
stabilizes.  The LLVM JIT fits in this picture as a second-stage
recompiler for when the code in the hot spots looks stable enough.


A bientot,

Armin



More information about the Pypy-dev mailing list