An experiment in static compilation of Ruby: FastRuby

http://blog.headius.com/2012/09/an-experiment-in-static-compilation-of.html

by jamesbritt • 14 years ago

50 25 14 years ago

blog.headius.com

jvoorhis• 14 years ago

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.

masklinn• 14 years ago

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/

qxcv• 14 years ago

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

regularfry• 14 years ago

I've had thoughts about doing a Rubinius bytecode interpreter in PyPy, but I can't find a decent reference to Rubinius' bytecode format other than the source. That'll take more time to wade through than I've got right now.

headius6• 14 years ago

JRuby does have an AOT compiler, but the resulting code must be shackled to the rather large JRuby runtime. Is also does a slower dynamic call that fastruby (except on invokedynamic).

My goal with fastruby is more to have a still dynamically-typed Ruby-like language without requiring anything more than virtual invocation and a modest runtime library (that can be statically optimized to only what's needed by e.g. Android toolchain).

VeejayRampay• 14 years ago

Extremely exciting.

python-guy• 14 years ago

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• 14 years ago

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 !

headius6• 14 years ago

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.

ps2000• 14 years ago

Mirah? Anyone?

kintamanimatt5• 14 years ago

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.

kristianp• 14 years ago

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

kintamanimatt5• 14 years ago

You may have missed the point of my comment: this isn't static compilation, but rather transcompilation. This isn't a bad thing, it's just mislabeled. FastRuby is implemented in a similar way to CoffeeScript.

headius6• 14 years ago

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.

kintamanimatt5• 14 years ago

No, what you've produced is a transcompiler which takes the source code from one language and converts it to source code in another language at the same high level. The fact there isn't a 1:1 mapping between the source language and the destination language isn't relevant. Strangely, it doesn't appear the Dragon Book mentions transcompilation, but Wikipedia has a decent definition: https://en.wikipedia.org/wiki/Transcompiler

This isn't static compilation in any sense of the definition as you're not producing a low-level language, i.e. assembly or machine code. Ultimately the JVM will do some combination of static and JIT compilation, but your code isn't doing this.

In no way am I deriding your effort, you've just got your definitions mixed up.

The JVM tends to run in a relatively large memory footprint compared to the MRI, although the JVM will execute faster when it's warmed up. The JVM isn't known for being frugal when it comes to memory usage. For long running processes, your transcompiler could be very useful.

damian2000• 14 years ago

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• 14 years ago

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.

headius6• 14 years ago

Efficient is a loaded term, so I'll skip that...but the JVM is most definitely a faster platform than CLR.

An experiment in static compilation of Ruby: FastRuby

Related Stories