An experiment in static compilation of Ruby: FastRuby

[kintamanimatt]

This is just transcompilation to Java, not actual static compilation. The performance gains will be offset by the increased memory footprint of the JVM.

Interesting nonetheless.

[headius]

I disagree :)

A transcompiler would have to be able to produce pretty much 1:1 mapping between one language and another. In this case, it would have to be emitting the equivalent of dynamic calls, which isn't really possible on the JVM (other than through invokedynamic, which does work very well).

Instead, this is using a static view of the world to produce the resulting code...assuming only the method names it sees statically at compile time will ever exist, and generating a static picture of that world. Hell...it's actually turning all dynamic dispatch into static dispatch. How could a transcompiler possibly do that?

Also...performance gains being offset by the size of the JVM? I don't understand this at all.

[kristianp]

I guess headius works with what he knows best, which is the JVM.

[python-guy]

I had tried this with python a while ago. Simply translating python code into C code using the objects in Python/C API gave up to 30% speedup. However, that is not much, considering the fact that python is up to 100 times slower than C. For speedups that are more significant, you really need type inference.

[jhchabran]

This reminds me Cython who provides optional types to speed up the critical path. The speed gains are pretty impressive. Having a such tool in Ruby would be wonderful !

[headius]

Did your experiment still do dynamic calls where Python would do dynamic calls? fastruby does not; all dynamic calls are converted into Java virtual dispatches, which optimize and inline like normal Java code.

The 30% improvement I got on "fib" was not as much as it would be for inferring the actual numeric types, but that's indeed possible here too. You should also keep in mind that the resulting code was by definition as fast as Java code would be doing the same work (i.e. all boxed math) so anything not math-related would actually be Java speed too.

[jvoorhis]

This reminds me of HipHop for PHP. HipHop lowers PHP to C++, with a direct mapping for control flow (control structures, exceptions) and a runtime library for everything else. Apparently it works very well.

[qxcv]

Interestingly, Facebook sponsored a project to build a prototype PHP interpreter using the PyPy[0] toolchain for JIT compilation, which turned out to be even faster than HipHop[1]. I have to wonder whether statically compiled Ruby would actually be any faster than a JIT interpreter like Rubinius, cold start JIT penalty aside.

Edit: looks like JRuby can/does do JIT compilation, but it is also capable of doing AOT compilation[2]. If JRuby can do AOT, then what is the point of FastRuby?

[0]: http://pypy.org/

[1]: http://morepypy.blogspot.com.au/2012/07/hello-everyone.html

[2]: https://github.com/jruby/jruby/wiki/JRubyCompiler

[masklinn]

An other project in the same class is Shed-Skin[0], a Python to C++ compiler (only handles a subset of Python though)

[0] http://shed-skin.blogspot.be/

[damian2000]

Anyone tried this approach via C# (CLR)? - it would be interesting to see the performance compared to the JVM. I'll give it a go if I get some time.

[fsiefken]

Is this related to using IronRuby vs JRuby? In benchmarks JRuby is significantly faster, odd as I suspect the CLR is slightly more efficient theoretically then the JVM.

[ps2000]

Mirah? Anyone?

[VeejayRampay]

Extremely exciting.