
PyPy Status Blog: First results of the JIT - iamelgringo
http://morepypy.blogspot.com/2009/09/first-results-of-jit.html
======
scythe
I think it'd be interesting if they included times for unladen-swallow as
well. I'm going to _guess_ that pypy is currently further along than u-s, but
I haven't done any comparison myself.

~~~
codexon
Do you have guess as to whether pypy will be production ready faster than
unladen-swallow?

~~~
scythe
Probably not. Since python is a dynamic language, there are issues with using
the llvm for optimization[1], but overall the llvm's code generator is
significantly more mature than pypy's which means that it'll probably be
easier to make unladen-swallow reliable.

[1] see <http://lua-users.org/lists/lua-l/2009-06/msg00071.html> and
<http://lua-users.org/lists/lua-l/2009-06/msg00069.html>

~~~
stephenjudkins
Note that PyPy supported LLVM as a backend until recently. It didn't get
nearly the love that the C backend did, apparently, and was removed because it
wasn't being maintained (see <http://codespeak.net/pipermail/pypy-
dev/2009q2/005143.html>). It was apparently 5x slower than the C backend.

I believe the difference is that unladen-swallow generates python code (JIT)
using LLVM, but PyPy generated the interpreter that way.

The JIT approach taken by PyPy is quite different than that taken by unladen-
swallow or other projects. Once completed, it can supposedly "turn the
interpreter of an arbitrary dynamic language into a just-in-time compiler for
the same language". However, as far as I can tell, the only working "backend"
for the JIT is x86. Why they don't leverage LLVM, I'm not sure, but it's
likely that they have good reasons.

PyPy is a very cool idea in that it provides RPython (a non-dynamic subset of
Python) as a DSL for creating dynamic languages. In theory, one could write
clean, beautiful, intention-revealing code that specifies a language, while
the JIT generator handles all the hard parts of making it fast. Unladen
swallow has the much narrower goal of leveraging LLVM to make Python bytecode
run faster.

Whether PyPy is too ambitious is hard to tell, but it's certainly way behind
schedule from what they had hoped when the project began. It's certainly a
really cool project that's worth keeping an eye on.

~~~
sjs
They are implementing the Futamura Projections. Very, very cool. I wouldn't be
surprised if a lot of existing tools just weren't built for their needs.

A fantastic explanation by sigfpe: [http://blog.sigfpe.com/2009/05/three-
projections-of-doctor-f...](http://blog.sigfpe.com/2009/05/three-projections-
of-doctor-futamura.html)

More generally: <http://en.wikipedia.org/wiki/Partial_evaluation>

