
The Ruby+OMR JIT - x3qt
https://developer.ibm.com/open/2016/11/18/introducing-ruby-jit/
======
skeptic2718
I expected CPython to have something like this, especially in 3.x but nothing.

If Ruby can get faster than Python sooner, I'd switch focus to Ruby (and
somewhat make Go less of a priority for us).

~~~
kweinber
Don't count on Ruby getting 10x faster anytime soon. The meta-object model and
method-missing reliance of many of the libraries make performance
optimizations of JITs a very limited enterprise.

~~~
sdegutis
And when you take those two things away, you pretty much just have Java.
Which, while it can be optimized, it's also Java.

~~~
pmontra
Java with Ruby's syntax and undeclared typing would make Java programs so
shorter that it would be worth it. But there would be nothing left of Java,
except the object orientation. It would just be a simpler more static Ruby.

~~~
dom0
You might want to look into Kotlin.

~~~
pmontra
No because it's statically typed, too much work programming like that and it's
not worth it for the kind of software I develop (backend of web/mobile apps),
but thanks. Suggestions are always appreciated.

I found a defunct Ruby like language called Reia a couple of days ago
[https://github.com/tarcieri/reia/](https://github.com/tarcieri/reia/) and
[http://reia-lang.org/](http://reia-lang.org/)

It's object oriented and runs on the top of the Erlang VM. It maps classes on
gen servers, which is pretty natural and it spares the developer all the
boilerplate of creating a gen server module. Unfortunately the language
designer killed it because "it's pretty bad to have two competing niche
languages with nearly identical features." The other language was Elixir.
However the two languages are very different. Elixir is 100% functional, Reia
could have been the language to transition millions of OO developers to a
functional and concurrent world. I could have used it instead of Ruby.

~~~
ryeguy
This is an odd stance. Backends are where static typing shine, and where those
who like static typing sing its praises. Maybe you just don't like static
typing?

I really don't find static typing to be more "work". You still have to think
about types in dynamically typed languages, you just get to skip specifying
them.

~~~
pmontra
Skipping that saves a lot of keypresses and time. I always found very little
help from static typing. I know what I'm doing if I type hash = {} in Ruby and
there is no need to declare it as HashTable (what else could it possibly be?).
About the types of the keys and values, they don't matter much in my
experience. Maybe it's Ruby or it's Rails, but they tend to fall right into
place without surprises.

~~~
evilduck
In case you're not aware, many static languages have implicit typing nowadays.
I still write Ruby most often, but for example in Go you could just write
`something := "string"` and with that := operator it'll manage the type
assignment for you. Lots of other static languages offer that now also. I'm
not well versed on modern Java, but the type system in Go pretty much gets out
of the way for the things I've done with it.

------
rubyfan
Anyone have any performance comparisons against other Ruby implementations? I
assume performance is the main reason someone would adopt this right?

~~~
vinceguidry
This is an improvement to standard MRI Ruby, also called CRuby. This is an
experimental JIT compiler which probably won't get adopted into mainline Ruby,
but will definitely cross-pollinate with it. A JIT compiler has been a goal in
MRI development for a long time. Nobody is likely to adopt this for anything,
it would take more work to get this working with the current installed base of
Ruby code than it would be to just rip ideas from it and put them into Ruby 3.
It's just cool as a proof of concept.

Other Ruby implementations suffer from not being compatible with the MRI
ecosystem, you have to port them over. In theory because they're the same
language, gems would be easily portable, but the sheer amount of combinatorial
work involved means they slowly accrete into separate ecosystems. It's
relatively easy to port a gem over and maintain it, but if you don't keep
doing it, they'll become incompatible.

MRI has the largest install base, and the biggest gem library, and the largest
number of eyes on it. Sure, JRuby and Rubinius are faster, but Ruby was never
a language chosen for speed, so most devs reach for MRI first and then only
branch out when requirements force them out.

For me, the differences between MRI and other implementations effectively make
them different languages, I'd jump to Elixir before giving JRuby a shot. I
have a sense that other Rubies, except maybe Opal, will always be niche.

~~~
LeanderK
As somebody not into the whole ruby-ecosystems: What's an example that breaks
compatibility between ruby and other implementations? And what's so wrong with
JRuby that you won't even consider it?

~~~
coldnebo
Re: jruby

I have considered it deeply. Many of our enterprise systems are Java-based, so
JRuby's ability to call Java methods directly without implanting services
would be a huge pragmatic boon. But every time I consider that I have to
balance it against being able to use a constellation of gems in Rails. For
example, nokogiri (libxml) is used in a ton of stuff. Sure there are Java
equivalents, but that isn't the issue. Rather I would have to reimplement or
find replacements for everything we use that depends on that without
introducing side-effects. In my experience that's really hard unless it's a
toy application without many dependencies. (Read: opposite of most enterprise
Ruby apps)

Also, as a gem author I've tried to support jruby along with MRI, but it
requires jumping through a lot more hoops. Of course any cross-platform code
requires more work to support, but it's a pressure on small devs. If no one
needs it, no one helps support it, so then it becomes another gem that is
effectively MRI-only. Kind of a viscous cycle.

~~~
rurounijones
> nokogiri (libxml) is used in a ton of stuff. Sure there are Java
> equivalents,

Nokogiri natively supports JRuby, no equivalent searching required.

CExts are basically the only place where this issue really pops up and all the
major CExt gems (Like nokogiri) support JRuby.

~~~
rubyfan
+1 nokogiri works like a champ on JRuby

------
magaudet
Author here: Feel free to AMA!

~~~
noahdesu
Slightly off topic since the post is specific to Ruby, but are you able to
compare OMR to Truffle and Graal?

~~~
magaudet
Not as well as I should be able to, for sure.

In my mind, I look at Truffle and Graal as a potential way forward to build
_new_ high performance JVM languages.

OMR I see as a way to build language runtimes in C/C++, and have a production
pedigree.

~~~
wgjordan
Related, are you aware of the JRuby+Truffle project [1]? Not a _new_ high
performance JVM language, but a high-performance implementation of Ruby using
Truffle and Graal. On the surface it sounds extremely similar to Ruby+OMR
(applying a high-performance, production-pedigree compiler/interpreter to an
experimental Ruby implementation), so I'd be interested in hearing about any
direct comparisons or knowledge-sharing between the two projects that might be
possible.

[1]
[https://github.com/jruby/jruby/wiki/Truffle](https://github.com/jruby/jruby/wiki/Truffle)

~~~
magaudet
I really enjoy meeting up with the JRuby+Truffle people whenever I can at
conferences. Though our approaches are really different, there's definitely a
cross-pollination of ideas: I've taken huge amounts of inspiration about what
could be possible from Chris Seaton's PhD work which was on JRuby+Truffle.

------
appleflaxen
Tried looking in github, project-specific pages, wikipedia and still have no
clue:

What does OMR stand for?

<something><something>runtime?

~~~
coldnebo
Doesn't seem to stand for anything (at least it's not defined in the project
charter).

If I had to guess at it:

Open Meta-Runtime

But I could see how that might be misinterpreted compared to their goals. Not
all cap names are acronyms?

[https://projects.eclipse.org/proposals/omr](https://projects.eclipse.org/proposals/omr)

~~~
forkandgrok
It stands for Open Managed Runtime.

~~~
rubyfan
Is the _Open_ really open, as in acceptable license that won't hold it back
from gaining adoption in OSS and Enterprise community - or - are there
licensing, patents or other proprietary strings attached?

~~~
sanxiyn
OMR is under Apache License.
[https://github.com/eclipse/omr](https://github.com/eclipse/omr)

------
poorman
"Right now, it only works for Ruby 2.1.5; however, I'm slowly plugging away at
moving forward towards Ruby 2.4."

The irony.

But in all seriousness, this is awesome.

~~~
magaudet
Whoops! That's actually an editing mistake: The Ruby+OMR preview is actually
for Ruby 2.2 right now.

You can follow the work in progress on trunk (what will become Ruby 2.4 in
December) here: [https://github.com/rubyomr-
preview/ruby/tree/ruby_2_4_omr_pr...](https://github.com/rubyomr-
preview/ruby/tree/ruby_2_4_omr_preliminary)

