

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

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

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

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

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

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

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

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

------
ps2000
Mirah? Anyone?

------
VeejayRampay
Extremely exciting.

