Home » forums » LtU Forum

Snakes all the way down

Virtual machines (VMs) emulating hardware devices are gen- erally implemented in low-level languages for performance reasons. This results in unmaintainable systems that are difficult to understand. In this paper we report on our experience using the PyPy toolchain to improve the portability and reduce the complexity of whole-system VM implementations. As a case study we implement a VM prototype for a Nintendo Game Boy, called PyGirl , in which the high-level model is separated from low-level VM implementation issues. We shed light on the process of refactoring from a low-level VM implementation in Java to a high-level model in RPython. We show that our whole-system VM written with PyPy is significantly less complex than standard imple- mentations, without substantial loss in performance.
* We show how the execution and implementation details of WSVMs are separated in the same way as those of HLLVMs.
* We show how the use of preprocessing-time meta-programming minimizes the code and decreases the complexity.
* We provide a sample implementation of a WSVM prototype for PyPy which exhibits a simplified implementation without substantial loss of performance (about 40% compared to a similar WSVM in Java).
(groan, since when did Java become the gold standard for "fast"? I know, I know, "with a sufficiently advanced JIT...") (I (sincerely, seriously) apologize if this is not nearly theoretical enough for a forum like LtU.)
By raould at 2014-12-19 00:23 | LtU Forum | previous forum topic | next forum topic | other blogs | 6169 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Link

http://scg.unibe.ch/archive/papers/Brun09aPyGirlTechreport.pdf

By johnwcowan at Fri, 2014-12-19 01:01 | login or register to post comments

d'oh

thanks.

By raould at Sat, 2014-12-20 07:23 | login or register to post comments

Surprised that an interpreter can compete with a JIT.

It seems like this is comparing an interpreter written in Java to a PyPy-generated JIT. This is a useful comparison, since it's roughly the same difficulty for an implementer. However, I'm surprised that the Java interpreter was even close.

I'd expect the RPython interpreter to be maybe half the speed of the Java interpreter. But I'd expect the PyPy-generated JIT to be much faster than either of those.

I wonder if maybe their RPython interpreter was a little too high level for the current PyPy to do a good job with. Or maybe my intuitions about this stuff are just out of date.

By Kannan Goundan at Wed, 2014-12-24 01:05 | login or register to post comments

Main difference is hinting

Really, the Java interpreter is just an un-hinted JIT. If the interpreter loop is tight, the JVM will JIT it in much the same way as PyPy will JIT your hinted interpreter loop. On the JVM, you're relying on the runtime to recognize a hot loop. In PyPy, you're relying on explicit jit_merge_point and can_enter_jit calls.

By Brandon Bloom at Wed, 2014-12-24 15:49 | login or register to post comments