6 ms·

Fast enough VMs in fast enough time

228 points by ltratt 15y ago

j_s 15y ago
"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.)
sjwright 15y ago
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.
- Wilduck 15y ago
  I agree, I learned a lot from this article. I also really appreciated the linked tutorials on writing a Brain Fuck interpreter and JIT compiler in PyPy/RPython: Part 1 [1] and Part [2]. The simplicity of the example and the good writing cleared the topic up for me immensely. [1] http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html http://morepypy.blogspot.com/2011/04/tutorial-writing-interp... [2] http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-jit.html http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-...
- justncase80 15y ago
  agreed. This was really good.
wisty 15y ago
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.
- judofyr 15y ago
  > _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. Basic structures like if, else, while etc. is easy. The hard part is the object model (including constant lookup) and long jumps (exceptions, next/break). Let's not forget the big core library which you need to implement if you want it to be usable at all… (Related: I started working on a Ruby version in JavaScript: https://github.com/judofyr/rubyscript https://github.com/judofyr/rubyscript)
  - mdaniel 15y ago
    > Let's not forget the big core library which you need to implement if you want it to be usable at all Wouldn't one just point the translator/compiler to whatever Ruby's equivalent is of /usr/lib/python2.7 and let it be "turtles all the way down"?
    - judofyr 15y ago
      Core != Stdlib. Core is implemented in C. There are 111 methods just on the String class in core…
- kingkilr 15y ago
  If anyone feels like paying my salary for a year, I'd love to work on this project ;) Not surprisingly, at the moment most (all?) of the PyPy developers are Python people, so none of us have invested time into a Ruby VM in our spare time, but it's definitely a cool project.
- Xylakant 15y ago
  Maybe because there's already a ton of working ruby implementations that all have their own sets of advantages. There's rubinous (which you named), they seem to be making pretty nice progress, there's mri, ree, maglev, macruby, ironruby and finally there's jruby which is actually often the fastest ruby interpreter around. It came a bit as a surprise to me that the author mentions jython as an example that languages on the hotspot vm don't benefit too much from its features - jruby certainly does.
iskander 15y ago
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?
- fijal 15y ago
  That has two sources - one is the complexity of the python interpreter the other is the complexity of the toolchain itself. Compiling converge takes ~5 minutes, while compiling python interpreter about 30minutes. There is definitely an ongoing effort to make it faster, for example by using the STM to parallelize it to multiple cores. PS. Type inference errors happen in roughly 1/5th of the compilation time. Not ideal, but better than waiting 30min.
haberman 15y ago
> 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.
- tomp 15y ago
  The difference is that LuaJIT would be tracing your interpreter, while PyPy tries to trace the user's program while it is being traced by your interpreter. Interpreter's loop is usually quite unpredictable and is therefore not the best candidate for tracing JIT optimization. PyPy, on the other hand, (IIRC) allows you to denote which variables belong to the interpreter and which belong to the user program, and so the traces would only guard on the user variables.
  - oconnor0 15y ago
    I wonder if it would be possible (or how difficult it would be) to modify LuaJIT to add what RPython provides: "tracing the user's program while it is being traced by your interpreter."
sb 15y ago
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.
- zellyn 15y ago
  Yeah: I wish speed.pypy.org also compared memory use. Admittedly, that's more complicated.
  - fijal 15y ago
    It does not for a very trivial reason - we lack benchmarks that have some reasonable memory impact. Right now most benchmarks would measure interpreter size, which is slightly boring
    - sb 15y ago
      Hm, I agree about having benchmarks with memory impact is more compelling, but wouldn't it be at least interesting to show the memory impact as it is right now? (i.e., how much more memory does PyPy need?)
codebaobab 15y ago
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 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.

228 points by ltratt 15y ago

j_s 15y ago

"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.)

sjwright 15y ago

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.

Wilduck 15y ago
I agree, I learned a lot from this article. I also really appreciated the linked tutorials on writing a Brain Fuck interpreter and JIT compiler in PyPy/RPython: Part 1 [1] and Part [2]. The simplicity of the example and the good writing cleared the topic up for me immensely. [1] http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html http://morepypy.blogspot.com/2011/04/tutorial-writing-interp... [2] http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-jit.html http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-...
justncase80 15y ago
agreed. This was really good.

wisty 15y ago

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.

judofyr 15y ago
> _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. Basic structures like if, else, while etc. is easy. The hard part is the object model (including constant lookup) and long jumps (exceptions, next/break). Let's not forget the big core library which you need to implement if you want it to be usable at all… (Related: I started working on a Ruby version in JavaScript: https://github.com/judofyr/rubyscript https://github.com/judofyr/rubyscript)
- mdaniel 15y ago
  > Let's not forget the big core library which you need to implement if you want it to be usable at all Wouldn't one just point the translator/compiler to whatever Ruby's equivalent is of /usr/lib/python2.7 and let it be "turtles all the way down"?
  - judofyr 15y ago
    Core != Stdlib. Core is implemented in C. There are 111 methods just on the String class in core…
kingkilr 15y ago
If anyone feels like paying my salary for a year, I'd love to work on this project ;) Not surprisingly, at the moment most (all?) of the PyPy developers are Python people, so none of us have invested time into a Ruby VM in our spare time, but it's definitely a cool project.
Xylakant 15y ago
Maybe because there's already a ton of working ruby implementations that all have their own sets of advantages. There's rubinous (which you named), they seem to be making pretty nice progress, there's mri, ree, maglev, macruby, ironruby and finally there's jruby which is actually often the fastest ruby interpreter around. It came a bit as a surprise to me that the author mentions jython as an example that languages on the hotspot vm don't benefit too much from its features - jruby certainly does.

iskander 15y ago

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?

fijal 15y ago
That has two sources - one is the complexity of the python interpreter the other is the complexity of the toolchain itself. Compiling converge takes ~5 minutes, while compiling python interpreter about 30minutes. There is definitely an ongoing effort to make it faster, for example by using the STM to parallelize it to multiple cores. PS. Type inference errors happen in roughly 1/5th of the compilation time. Not ideal, but better than waiting 30min.

haberman 15y ago

> 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.

tomp 15y ago
The difference is that LuaJIT would be tracing your interpreter, while PyPy tries to trace the user's program while it is being traced by your interpreter. Interpreter's loop is usually quite unpredictable and is therefore not the best candidate for tracing JIT optimization. PyPy, on the other hand, (IIRC) allows you to denote which variables belong to the interpreter and which belong to the user program, and so the traces would only guard on the user variables.
- oconnor0 15y ago
  I wonder if it would be possible (or how difficult it would be) to modify LuaJIT to add what RPython provides: "tracing the user's program while it is being traced by your interpreter."

sb 15y ago

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.

zellyn 15y ago
Yeah: I wish speed.pypy.org also compared memory use. Admittedly, that's more complicated.
- fijal 15y ago
  It does not for a very trivial reason - we lack benchmarks that have some reasonable memory impact. Right now most benchmarks would measure interpreter size, which is slightly boring
  - sb 15y ago
    Hm, I agree about having benchmarks with memory impact is more compelling, but wouldn't it be at least interesting to show the memory impact as it is right now? (i.e., how much more memory does PyPy need?)

codebaobab 15y ago

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 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.