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 _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
