[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