Rubinus or MRI 1.9.3 (YARV)?

Question

So, I have a few questions that I have to ask, I did browse the internet, but there weren't too many reliable answers. Mostly blog posts that would cancel each-other out because they both praised different things and had benchmarks to "prove their viewpoint" (I have never seen so many contradicting benchmarks in my life).

Anyway, my questions are:

• Is Rubinius really faster? I was pretty impressed by this apparently honest pro-Rubinius presentation. Another thing that confuses me a little is that a lot of Rubinius is written in Ruby itself, yet somehow it is faster than C-Ruby? It must be a pretty damn good implementation of the language, then!
• Does EventMachine work with Ruinius? As far as I know, EventMachine partially relies on Fibers (correct me if I'm wrong) which weren't implemented until 1.9. I know Rubinius will eventually support 1.9, too; I don't mind waiting a little.
• Do C extensions work in Rubinius? I have written a C extension which "serializes" binary messages received from a TCP stream into Ruby Objects and vice-versa (I suppose the details are not important, but if it helps answer this question I will update the post). This can be a lot of messages! I managed to write the same code in Ruby (although, it made little sense after a month), but it proved to be a real bottle-neck in the application. So, I had to use C as a "solution" to my problem. EDIT: I just remembered, I use C for another task, it is a hit-test method for Arrays. Basically it just checks if a "point" is inside an a polygon, it was impossibly slow in CRuby.
• If the previous answer was a "No," is there then an alternative for C extensions in Rubinus? I gather the VM is written in C++, so that then.

A few "bonus" questions:

• Will C-Ruby (2.0+, YARV) ever get rid of GIL? Or at least modify it so CRuby supports true parallelism?
• What is exactly mruby? I see matz is working on it, and as far as the description goes it seems pretty awesome. How different is it from CRuby (performance-wise)?

I apologize for this text-storm I unleashed upon you! ♥

Verrocchio

Good question. i'd answer if I new the answer! – Kaddish

This should really be multiple questions. You also haven't shown any own research into them. – Selfinduction

I mean, the answer to your question about the extensions is right on the Rubinius home page. – Selfinduction

As for getting rid of the GIL, going by the Python discussion on it, the answer is probably "not very likely". The Python interpreter maintains very complex internal data structures, attempts to synchronise access to them at a finely grained level have yielded unacceptable performance hits. It's not a stretch to assume that the situation with Ruby is the same. – Selfinduction

@Selfinduction 1. All the questions are closely related. Why clutter SO? This also makes it easier for someone in a position similar to mine find answers. 2. All the research is mostly consists of heavily opinionated blog posts which claim "x rocks, y sucks," and of obviosuly biased articles about one or the other implementation. 3. All that link said is that they want to be compatible with the C API, and to an extent are. I personally don't find that as enough information, or proof. 4. Thank you for that useful comment about my GIL-related question. – Verrocchio

@starship: 1. Why clutter SO? Because focused questions of a manageable size are easier to search for on Google, and easier to write answers for. 2. By research, I meant "install it and try the extensions you need for yourself." The blog posts are biased because there's so many differences between the two that an exhaustive objective assessment is an intractable task. Determining whether it's good for your purposes isn't, as long as you know what your requirements on the implementation are. – Selfinduction

@starship 3. You edited your post to mention the C extensions are ones you wrote. How do you expect anyone else to tell you whether an extension they can't install and test works? That said, I believe one of the development goals of Rubinius is to make number-crunchy Ruby code run faster. It's possible it'd make your Ruby implementation of the latter code fast enough. (Again, the way to find this out is to benchmark and compare.) – Selfinduction

My understanding is that Rubinius compiles ruby to byte-code, then uses a JIT VM, and that the compilation to bytecode is done in ruby, but the VM itself is written in c++, so you get the speed benefit of c++ when executing, but a high level language is used to do the more complex task of parsing and compiling the source code. – Mineralogist

Answer 1

Is Rubinius really faster?

In most benchmarks, yes.
_{(source: google.com)}

_{(source: google.com)}

But benchmarks are... dumb. Apps are what we really care about. So the best thing to do is benchmark your app & see how well it performs. The 2 areas where Rubinius will real shine over MRI are parallelism & memory usage. Rubinius has no GIL, so you can utilize all available threads. It also has a much more sophisticated GC, so in general it could perform better with respect to GC.

I did those benchmarks back in Oct '11 for my talk on MagLev at RubyConf

Does EventMachine work with Rubinius?

Yes, and if there are parts that don't work, then the issue should be reported. With that said, currently the EM tests don't pass on any Ruby implementation.

Do C extensions work in Rubinius?

Yes. I maintain the compatibility issue for C-exts, so if there is one you have that is tested on Travis, Rubinius would like to see it pass against rbx. Rubinius has historically had good support for the C-api and C-exts, though it would be nice if someday Rubinius could run Ruby so fast one would not need C-exts or the C-api.

Will C-Ruby (2.0+, YARV) ever get rid of GIL? Or at least modify it so CRuby supports true parallelism?

No, most likely not. Jesse Storimer has a succinct writeup of Matz's opinion (or lack thereof) on threads from RubyConf 2012. Koichi Sasada tried to remove the GIL once and MRI perf just tanked. Evan Phoenix also tried once, before he created Rubinius, but didn't have good results.

What is exactly mruby?

An embeddable Ruby interpreter, akin to Lua. Matt Aimonetti has a few articles that might shed some light for you.

Somite

Oh, this answer is brilliant! :D Thank you so much! – Verrocchio

Answer 2

I am not too much into Ruby but I might be able to answer the first question.

Is Rubinius really faster?

I've seen different Benchmarks telling different things. However, the fact that Rubinius is partially written in Ruby does not have to mean that it is slower. I thought the same about PyPy which is Python in Python. After some research and the right classes in college I knew why.

• As far as I know both are written in a subset of their language which should be much simpler. An (e.g. C) interpreter can be be optimized much easier for such a subset than the whole language.
• Writing the Ruby/Python interpreter in its own language allows much more flexibility and quicker prototyping of new interpretation algorithms. The whole point of the existence of Ruby and Python are among others that algorithms can be implemented much quicker than in e.g. C or even assembler. A faster algorithm outweighs the little overhead of an interpreter a lot of the time.

Btw. writing an interpreter for a language in the same language is also a common academic practice to show how mighty the language is. In one class we've written Lisp in Lisp in Lisp.

Catch

I can't say this completely answers my question, but seeing as it is the only one, and that it answers a portion of the question, I will mark it as accepted. Thanks! – Verrocchio

Well, it's hard to answer all your questions at once :). Your mruby question is actually answered on Github: What's mruby mruby is the lightweight implementation of the Ruby language complying to (part of) the ISO standard. mruby can be linked and embedded within your application. So it seems that its primarily use will be to enhance applications with some sort of Ruby scripting such as Lua. Think of it like C Extensions the other way around. Instead of using C libraries within Ruby you can use Ruby within your C program. It's only a guess. – Catch