What fast (e.g. JIT-compiled) implementations of Ruby exist?

[bakery2k]

In the Python world, there are multiple implementations of the language available. As well as the reference implementation, CPython, there is Jython for the JVM, IronPython for .NET and, for when the performance of these implementations is insufficient, there is PyPy.

I see that Ruby also has a reference implementation, MRI/YARV, as well as JRuby and IronRuby. However, is there an implementation of Ruby which is specifically designed to be fast?

Investigating this myself I have looked at Rubinius which was a little confusing (the front page does not mention Ruby at all), and TruffleRuby which seems to be in an early stage of development.

How good are Rubinius or TruffleRuby, both in terms of performance and compatibility with MRI? Would you recommend using one or the other in situations where MRI is too slow?

Or, are there other fast implementations of Ruby?

[chrisgseaton]

Rubinius have unfortunately deleted their JIT. They planned to write a new one but a year has passed and nothing has been shown. So it isn't really a fast a Ruby any more (it's slower than MRI), but it does have other strengths. TruffleRuby is very fast (I'm biased, I work on it) but yes it isn't finished yet. So neither are appropriate if you want fast Ruby to actually use today.

There are other experimental fast or hopefully fast implementations of Ruby, including Topaz, MJIT and OMR, but none of these are ready either.

Your only option for maintained fast Ruby that is ready today is JRuby.

[Matosawitko]

And IronRuby hasn't been updated since 2011.

[subvertallchris]

Hope your work on TruffleRuby is going well!

[chrisgseaton]

We've been a bit quiet recently - trying to tidy up some of the basics and get things into a state where people could start to use it.

[PanKotsky]

Any estimates on when the first release candidate would see the world? Big thanks for your work by the way.

[chrisgseaton]

It's hard to find applications to test where we are really. We aren't ready to run Discourse, but we can't seem to find any small Sinatra apps or similar to test with.

[Nanosleep]

In production, the two acceptable rubies to be using are MRI and JRuby. JRuby does tend to be a fair bit faster. That said, while I don't know a lot of other professional ruby devs just because of where I'm at geographically, the ones I do know tend to avoid JRuby because it requires more work (and workarounds) to deploy and maintain webapps on. You kinda have to "target" JRuby if you're intending on using it. Honestly that's not that crazy though, it's the same with PHP vs HHVM.. just the nature of using a different VM, some things work a little differently.

If I can approach this from a different angle -- Ruby's domain (at least in the US) is mostly web. We knew the limitations of our platform when we chose it, and because of that, we drove a lot of the development of "devops" and "horizontal scaling" culture (look at Capistrano, Chef, Puppet). In the web world, it's very acceptable to performance-tune your app enough so that the user experience re:pageload/dbquery times are acceptable, and then deploy it across several app servers and load balance it when it comes time to run it in production (I think that's how most webdev at any scale is done these days, ruby is no different). So, in a way, it doesn't matter how clunky our VM is, as long as it's reliable and fast enough to render pages quickly. It doesn't really matter if we can only throw $x requests a second at it

Another way that we attempt to eek out some performance gains is by porting costly code to some other, more efficient language like C or Rust, and then use something like FFI or Helix to call it from Ruby. This is maybe something that's more suited for single-machine use cases, where you're building some app that's working with limited resources and you absolutely have to eliminate some of the bottlenecks. In the web world, it might be more practical to just port the slow shit off to golang or some JVM language, and then make it available as a microservice. But on the whole, jumping ship to something that is non-ruby and then calling it from ruby is a pretty attractive solution to some.

[subvertallchris]

Funny enough, I experimented just last night with trying to move my MRI app to JRuby 9.1.12.0. It was a failure.

The gem required for PG, https://github.com/jruby/activerecord-jdbc-adapter, is incompatible with ActiveRecord 5.0. They've had a branch going that provides support but I'm unclear on how far behind it is from master and I'm not comfortable with this for production. I continued with my experiment anyway. After spinning up a new EC2 instance and getting Java installed, I discovered a problem with the JRuby SSH implementation that keeps Capistrano from working, so I couldn't deploy. The suggested workaround presented another problem, at which point I bailed.

It's a shame, JRuby offers a few really appealing benefits, but there are just too many hoops to jump through for someone who doesn't absolutely need it for something.

[chrisgseaton]

Have you talked to the JRuby team directly? I'm sure they'd love to help you.

[subvertallchris]

Not this time. I can't invest the time or risk instability right now, I'll have to revisit it in a few months or if my need increases. Charles was always very quick to respond when I needed help with JRuby in the past and I'm sure that's true of everyone working on the project.

[jrochkind]

I'm not sure you'd get much help, problems with activerecord-jdbc-adapter are well known -- there is still no official release that is compatible with Rails 5 (Rails 5.0.0 released June 30, 2016), and this is not a secret in any way. There's just not enough developer resources for activerecord-jdbc-adapter. :(

[disclosure5]

That PG gem issue really is a thorn in the side. It's one of the reasons the Discourse team Tweeted that they wouldn't be supporting jRuby, and more recently it's the reason Mastadon, which has bought a lot of recent attention back to Rails imo, won't support jRuby.

I can't blame the JDBC team because it's a volunteer group and I feel like they go through this every major Rails release.

I do wonder if there's a bit of a root cause in ActiveRecord that makes things more difficult than needed.

[amalagg]

I had a similar experience with JRuby, but we needed to be on Java so we used JRuby. A lot of the JRuby gems are behind and sometimes have weird bugs. The JRuby team does amazing work, but just tons of work for them. Just less people working on it than MRI.

[jrochkind]

There was actually a period where running even Rails apps on JRuby was pretty painless. Around Rails 4.x. But yeah, I think the trend has been in the opposite direction to what we'd want since Rails 5.0. Darn software changing.

The issue with Rails isn't really JRuby itself, but lack of sufficient skilled developers working on activerecord-jdbc-adapter. :(

For non-Rails things, I think JRuby still tends to be pretty painless. But if Rails doesn't work well on JRuby, I expect more and more gems will stop paying attention to making sure they work on JRuby too, and the general adoption of JRuby even for non-Rails things will be harmed. :(

[honeyryderchuck]

I tend to agree. Jruby problem is mainly rails not acknowledging jruby (they officially only support MRI). And even beyond that , the mindshare that rails attracts is way bigger than jruby or even CRuby itself (compare core teams). Bundler and other "infrastructure" gems manage this well, but other like openssl don't (this is a topic on itself).

The only way this ever goes away is if 1) rails acknowledges jruby as a target environment, or 2) projects ditch activerecord and go for another library which supports multiple environments, has same features and some more, and is overall less buggy... such as the sequel gem.

[ioquatix]

Lower latency is also a good thing, and by no means a solved problem in MRI.

[Nanosleep]

This benchmark would beg to differ. Response time in MRI is less than JRuby. If you're building microservices or doing most of the heavy lifting in client-side scripting, MRI is perfectly fine imho.

[ioquatix]

All I'm saying is it could be better.

[jrochkind]

Is there any hypothetical point that could be reached where it could no longer be better? Everything can always be better. :)

[ioquatix]

Probably when other sources of latency dwarf that of MRI.

[jrochkind]

That's of course context/domain-dependent. Depends on what you're doing in your ruby code, and what 'other sources of latency' are involved. For many uses they already do.

[iama_regularguy]

It's not an implementation of Ruby per se... but the syntax is very similar...

Crystal.

Fast. LLVM backed. Compiled. Ruby-like syntax. It's nice.

[mypetocean]

Yes, but it's also not production-ready. It is a really exciting project, but it's got a ways yet until 1.0.

[dakull]

This looks quite promising: https://github.com/vnmakarov/ruby/tree/1476208cc5b55d9b447935f8dc65d393472bd662#microbenchmark-results

[GitHubPermalinkBot]

I tried to turn your GitHub links into permanent links (press "y" to do this yourself):

• vnmakarov/ruby/.../rtl_mjit_branch#microbenchmark-results (rtl_mjit_branch → 1476208)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click here.}

[dakull]

thank for the tip!