This is the most interesting thing I've read on hacker news for months. And that's despite its subject matter being way beyond my skill level. I actually understand how a tracing JIT works now.

> RPython badges itself as a meta-tracing system, meaning that the user's end program isn't traced directly (which is what Figure 1 suggests), but rather the interpreter itself is traced.

Isn't that exactly what would happen if you wrote an interpreter in any language with a tracing VM (ie. LuaJIT)? How is writing an interpreter in RPython better than writing one with LuaJIT? RPython makes you insert these hints to the trace compiler (can_enter_jit, jit_merge_point) about when to start/stop running a trace, does this buy you anything? If I had to guess, I'd suspect that this is actually a net loss because you have to guess ahead-of-time where it would make sense to start tracing. This sort of guessing is notoriously hard to do. An implementation like LuaJIT automatically decides when to start tracing based on run-time behavior, which seems like a more robust approach.

The one thing I do find very interesting about RPython is how it subsets a dynamic language such that types can be statically analyzed. I always wondered whether this was possible and what kind of restrictions you'd have to enforce. It's great to see an actual example of this -- it will be very instructive to anyone trying to do a similar thing.

But as far as using RPython as a "meta-tracing system," I'm not seeing what's ground-breaking here. I'd bet 50 cents that writing an interpreter in LuaJIT will be faster than writing it in RPython. And if I'm wrong about that, I'd bet 50 more cents that the reason RPython wins is because it's statically analyzable, not because of anything that's unique about its "meta-tracing system." I'm not sure that term really means anything.

While I find it good that the article explicitly addresses issues with trace-based compilation (usually this is not the case), a completely fair account needs to present the additional memory requirements for using the PyPy tool chain. Quite recently, somebody here has addressed this by mentioning that he does not really care for all the performance speedup he gets, if the memory requirements become outlandish at the same time.

It would also be very informative to know what the differences in automatic memory management techniques are (i.e., what did the previous implementation do?) Personally, I am also interested in interpreter optimization techniques, and it would therefore be interesting to me what--or if at all--the previous VM used for example threaded code or something along these lines.

"What RPython allows one to do is profoundly different to the traditional route. In essence, one writes an interpreter and gets a JIT for free. I suggest rereading that sentence again: it fundamentally changes the economics of language implementation for many of us. To give a rough analogy, it is like moving from manual memory management to automatic garbage collection."

(RPython being the foundation of PyPy.)

I'm surprized there's not a PyPy version of Ruby. _why's unholy showed it's trivial to compile Ruby into Python (in many cases). It shouldn't be too hard (famous last words) to make a Ruby VM with PyPy. If they don't like the idea, they could make a RPython <-> RRuby translator, and port the whole thing to RRuby.

Yes, I've heard about Rubinous (the Ruby equivalent to PyPy), but it doesn't have the resources.

Squeak Smalltalk bootstrapped itself (back in 1996) by implementing its virtual machine in Slang, a subset of Smalltalk that can essentially be pretty-printed into C.

Back to the future: the story of Squeak, a practical Smalltalk written in itself. http://www.vpri.org/pdf/tr1997001_backto.pdf

Its a neat twist that RPython is taking the same engine that optimizes the VM to JIT code that runs on the VM.

Very cool article. I have to admit I'm a little frightened of the bulk and complexity of the RPython translation pipeline. I'm not happy about the prospect of waiting an hour to learn my code runs afoul of poorly documented type inference logic. Perhaps when PyPy stabilizes the team can trim back some of the abandoned paths and speed up translate.py?