Hacker News Reader

Comment by towski | Hacker News Reader

The only question I have is, how much work is it to create a C based ruby without a global interpreter lock.

Matz mentioned off hand at the last Ruby Conf that Nobu has been experimenting without the GIL. It's scary because running code without the GIL will expose a lot of existing concurrency bugs that have been safely hidden thus far. A lot of code works fine with the GIL, since it prevents the full parallelism that would exercise all possible race conditions, so it's unlikely they'd remove it in anything other than a major release, i.e. Ruby 3.0

An other issue, the one CPython has hit repeatedly when trying to remove the GIL — and the big sticking point for the core team in general — is that single-threaded performances of a naive interpreter suffer a lot when splitting the GIL: instead of a single lock which is taken and released relatively rarely, the interpreter has to juggle with many small locks which it has to acquire and release much more often. When David Beazley looked back on the GIL-less patch for CPython 1.4[0] he measured performance hits of 4x~7x.

Though in the case of CPython most of the cost comes from the refcounting. MRI is not refcounted so the performance hit of finer locking would probably be lower.

[0] http://dabeaz.blogspot.be/2011/08/inside-look-at-gil-removal...

This is where JRuby / Truffle is exciting - JRuby's been exciting for a long time and never quite reached it's potential, but with these latest projects it could become the main ruby implementation - and these complex issues are already largely solved in the JVM.

I really doubt jruby will ever become the main ruby implementation, as awesome as it is. The fact is that too much of the ruby ecosystem is built on calling out to C, and jruby officially abandoned cext shimming a while back. And while ffi is good, it's often not nearly as flexible.

There's also the fact that because of slow startup times, the modify/test cycle can be quite frustrating compared to working with MRI.

The truth is that the vast majority of ruby applications never reach a point where the steady-state post-warmup performance of jruby with pure ruby outweighs the fast-startup moderate performance of mri+cexts. And ones that do reach that point often have a better case for moving to something else anyways (including other jvm technologies that can now be shimmed on via jruby and eventually replace the whole thing).

> C, and jruby officially abandoned cext shimming

Jruby + truffle + cext, however is becoming a possibility.

http://www.chrisseaton.com/rubytruffle/cext/

Huh. That is a really interesting approach, and I was not aware of it. Thanks.

I haven't looked deeply, but this seems like something where the edge cases will be tricky, though.

Truffle can reach faster performance in pure-ruby than MRI+cext. Agreed though, it'll be a uphill battle to change the interpreter of choice, and JRuby will have to have much faster startup to get it to work

We're working on an AOT compiled build of JRuby Truffle that has no dependency on the JVM and starts about as fast as MRI, but it's not public yet.

That's awesome - so it'll have a JVM of sorts bundled within it but that's totally hidden, it runs just like MRI? How does memory usage compare - running JRuby on a 512mb dyno would be sweet.

What you + the jruby team is doing is truly awesome, at some point I'll have to try my hand at contributing to it :)

Yeah, but it's not just bundled - to me that it sounds like we just link against a JVM library to produce a binary. What we do is to compile the Ruby interpreter, the JIT compiler and the JVM runtime in one big step - whole program analysis.

Memory usage and startup time are comparable to MRI - http://www.oracle.com/technetwork/java/jvmls2013wimmer-20140... see slide 19.

If you want to contribute there are beginner bugs (admittedly you need to be a fairly confident beginner) at https://github.com/jruby/jruby/issues?q=is%3Aopen+is%3Aissue....

Is there a write up somewhere about why they abandoned cext support? That would be interesting and I couldn't find one.

He also tweeted this awhile ago: https://twitter.com/yukihiro_matz/status/495219763883163648

"My vague plan for Ruby GIL is 1) add more abstract concurrency e.g. actors 2) add warning when using threads directly 3) then remove GIL"

Creating MRI/CPython/Perl5-style VM without GIL is not much harder than creating the same thing with GIL. But the problem is that converting existing implementation to not use GIL is comparable amount of work.

Reply on news.ycombinator.com