5 ms·

An experiment in static compilation of Ruby: FastRuby

50 points by jamesbritt 14y ago

jvoorhis 14y 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 14y 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/ http://shed-skin.blogspot.be/
- qxcv 14y 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/ http://pypy.org/ [1]: http://morepypy.blogspot.com.au/2012/07/hello-everyone.html http://morepypy.blogspot.com.au/2012/07/hello-everyone.html [2]: https://github.com/jruby/jruby/wiki/JRubyCompiler https://github.com/jruby/jruby/wiki/JRubyCompiler
  - regularfry 14y 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.
  - headius 14y 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).
    - hencq 14y ago
      Could this be mixed with Mirah to have it dynamically typed, but with types added where needed for performance? Sort of like Dart's optional typing, but for the JVM.
VeejayRampay 14y ago
Extremely exciting.
python-guy 14y 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 14y 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 !
- headius 14y 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 14y ago
Mirah? Anyone?
kintamanimatt 14y 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 14y ago
  I guess headius works with what he knows best, which is the JVM.
  - kintamanimatt 14y 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.
    - ryanbraganza 14y ago
      I don't disagree. Although, I think CoffeeScript is more similar to JRuby than FastRuby.
      - batista 14y ago
        In what possible way is CoffeeScript more similar to JRuby than FastRuby??? JRuby is an actual compiler to JVM bytecode. FastRuby is translating to Java. If anything, FastRuby is the SAME THING as CoffeeScript.
    - headius 14y ago
      CoffeeScript is a transcompiler because it's largely just taking language A with semantics similar to JavaScript but different syntax and converting it directly to JavaScript. There's no static worldview as in fastruby, no exploitation of that worldview, and no fundamental differences between CoffeeScript and JavaScript.
      - kintamanimatt 14y ago
damian2000 14y 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 14y 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.
  - headius 14y ago
    Efficient is a loaded term, so I'll skip that...but the JVM is most definitely a faster platform than CLR.

50 points by jamesbritt 14y 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 14y 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/ http://shed-skin.blogspot.be/
qxcv 14y 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/ http://pypy.org/ [1]: http://morepypy.blogspot.com.au/2012/07/hello-everyone.html http://morepypy.blogspot.com.au/2012/07/hello-everyone.html [2]: https://github.com/jruby/jruby/wiki/JRubyCompiler https://github.com/jruby/jruby/wiki/JRubyCompiler
- regularfry 14y 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.
- headius 14y 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).
  - hencq 14y ago
    Could this be mixed with Mirah to have it dynamically typed, but with types added where needed for performance? Sort of like Dart's optional typing, but for the JVM.

VeejayRampay 14y ago

Extremely exciting.

python-guy 14y 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 14y 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 !
headius 14y 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 14y ago

Mirah? Anyone?

kintamanimatt 14y 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 14y ago
I guess headius works with what he knows best, which is the JVM.
- kintamanimatt 14y 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.
  - ryanbraganza 14y ago
    I don't disagree. Although, I think CoffeeScript is more similar to JRuby than FastRuby.
    - batista 14y ago
      In what possible way is CoffeeScript more similar to JRuby than FastRuby??? JRuby is an actual compiler to JVM bytecode. FastRuby is translating to Java. If anything, FastRuby is the SAME THING as CoffeeScript.
  - headius 14y ago
    CoffeeScript is a transcompiler because it's largely just taking language A with semantics similar to JavaScript but different syntax and converting it directly to JavaScript. There's no static worldview as in fastruby, no exploitation of that worldview, and no fundamental differences between CoffeeScript and JavaScript.
    - kintamanimatt 14y ago

damian2000 14y 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 14y 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.
- headius 14y ago
  Efficient is a loaded term, so I'll skip that...but the JVM is most definitely a faster platform than CLR.