This is my favorite project we have at Engine Yard. I've been rooting for it and fighting to keep it alive for years now because I know that this is the future of ruby. Evan and Brian and all the contributors have done great work on this ambitious project.
I've had ruby aliased to rbx on my own personal laptop and run all of my development on rbx, I only have to bust out MRI every once in a while, like once a month. I write lots of code with event machine, redis, amqp and many other complex parts of ruby ecosystem and for the most part they all just work on rbx.
Huge congrats to rubinius team again, I predict this will be the default ruby for most people inside of a year if not 6 months.
Its a totally different beast, not an apples to apples comparison.
EE is simply a patched MRI, so it will be faster on strings (known issues with rbx), but rbx has generation GC and JIT which can only improve.
Right now in my limited testing the performance is a wash, but if your app is memory hungry the improved GC is worth it alone. If your app is CPU heavy the JIT becomes your friend. The only way to be sure its to test it (how about running your test suite on it?), but I suspect rbx is going to get very fast as soon as a few big players shift on to it and the sweet spots for the tuning knobs are discovered.
One thing I'd appreciate with these kinds of announcements is a "what is it" paragraph preferably towards the top of the referenced web page. I suppose if I were working in Ruby I'd know what Rubinius is and why I'd care but a list of "what is new" doesn't particularly help me or folk like me.
From http://rubini.us you can read "An environment for Ruby, the programming language that provides performance balanced with accessibility, focusing on improving programming productivity"
The thing is, in this context, what is "an environment for ruby"?
Here's Wayne Seguin's take on Rubinius (he's the developer behind rvm, and he puts it nicely, I think):
Rubinius is a ruby interpreter written in C++ using many advanced techniques and technologies such as LLVM, a "precise, compacting, generational garbage collector", a compatible C extension api to standard MRI Ruby and many other awesome ideas that will give any language nut a huge nerdon.
Wherever possible Rubinius is written in Ruby. Where not possible (yet), it's C++.
And further down:
The Rubinius bytecode virtual machine is written in C++, incorporating LLVM to compile bytecode to machine code at runtime. The bytecode compiler and vast majority of the core classes are written in pure Ruby.
So, it's the VM that's C++. The bytecode compiler (which is technically what's meant by "interpreter" in this case) is ruby.
Sure, but the point I'm trying to make is that Wayne Seguin was using the word "interpreter" colloquially to refer to the whole program, in effect saying that the whole code base is C++.
If you worked in Ruby you'd definitely know that Rubinius is one of the next-gen Ruby VMs. Since you don't work in Ruby, the whole project matters a lot less to you.
Would love to see a big fat link on the front page that says "Help make the best Ruby implementation ever. Join us!" with a link to the google group. Clear call to action.
Blog wise: Bubble up some of the great activity going on behind the scenes. Design decisions, great implementation debates, calls for help on hard/easy problems, new releases, beta releases, testing calls, etc. The posts don't have to be more than a paragraph or two. Just enough so we can see where you guys are steering the ship and if there's something we can do to help.
I'm sure there are more than a handful of potential up and coming language implementers that Rubinius could help inspire and recruit. All it takes is an easy to find/read active conversation to get them engaged.
Also, I'm sure you're thinking about a 'the long road to 1.0' post. That would be great first post to talk about all the decisions and direction changes that lead up to the current design.
I think now that we've hit 1.0, the path forward is easy to break up into bits could be on the blog. Before the 1.0-rc cycle, it was hard to separate out individual things.
Given that people think this is a good idea, I think we'll go ahead and do it!
Please do! The number of vaguely interesting Ruby blogs that are updated frequently has taken a tumble in the last year or two. I need more to link to ;-)
Very cool! I use Ruby 1.9.1 and JRuby 1.5 for production, but Rubinius may become dominant in the future because of using LLVM and because the code base must be much easier to work with.
I'd like to see if / how many of my unit tests pass using Rubinius, but does it currently support 1.9-specific code?
Also, RVM installs RC2, not the 1.0 release. Maybe someone can give them a poke...
UPDATE: Nevermind, http://rubini.us clearly states that 1.9 compatibility will happen post-1.0. Can't wait, even if it's just to know that my code is compatible with what may be a very real option in the years to come.
AND: I should probably run "rvm update" first, to get the 1.0 release...
Now this is where Ruby is winning, so many different implementations, and that too successful ones! I love the community. Congratulations to the team. :-)
I'm just starting to get into Ruby but I'm pretty confused about this project. It sounds really cool, but doesn't Ruby 1.9 already have a GC and compiles into byte code? Maybe 1.9 doesn't have a JIT but couldn't they add it?
Ruby has had a GC since the start; it's a conservative stop-the-world all-or-nothing non-compacting mark-and-sweep garbage collector. Meaning:
1. It can't tell the difference between a number on the heap that happens to look like a reference to some active data, and an actual reference to some active data. Hence it has to be conservative, and assume anything that looks like a reference, is one. Rubinius has a precise GC, and so doesn't suffer from this problem, which can lead to dead objects never being collected.
2. The GC has to stop the VM while it's running. This is probably also the case with Rubinius, however:
3. It has to walk over every object in the VM in one go, so it gets progressively slower the more objects you have. Rubinius has a generational GC, where objects are split into pools based on how long they've been alive for, and these can be scanned individually and at different rates appropriate to their age (i.e. long-lived objects probably aren't worth checking very often).
4. It can't move objects around; when it frees something, it leaves a gap where the object used to be. If a new object doesn't fit there, it has to go somewhere else, wasting that space. In the long run this can lead to memory fragmentation. Rubinius has a compacting GC, allowing it to fill in these holes and make better use of memory, and also better use of CPU caches.
Yes, 1.9 compiles to bytecode, and yes in theory a JIT could be added to it, but that's a pretty big project.
Cool. Is Rubinius faster than 1.8.6 or even 1.9? Was that the goal? Or is it just a 1.0 milestone where the project is compatible enough to meet the 1.8.6 ruby language spec and native libs?
The biggest goal, at least a few years ago, was to have a Ruby that is substantially implemented in Ruby, as opposed to being a hundred thousand lines of C under the hood. Paradoxically, this can result in speedups, since it's easier to optimize expressive, well-written code. Avi Bryant gave a talk at RailsConf a few years ago about how Smalltalk contains all the "features" of Ruby that are usually blamed for its performance woes, but still managed to be pretty fast. It's not the language features that keeps Ruby slow; it's the opaque implementation.
I think they are on the right track. Given that this is a 3 year old project, I don't think we can compare it to smalltalk implementation with years of development. I wonder how well it would compare to something like pypy and other similar projects.
Can't blame them, even a year or two ago Ruby and RoR were much inferior to today. And wait till RoR3 hits the shelves full steam. Granted I hope ActiveRecord3 will include everything by default like DataMapper does but whatever...
Ruby is still in infancy stages, Python is quite old. Hell Python was the inspiration for Ruby.
I mean look at what is happening in the Javascript space. If Ruby and JRuby implementations get really f-ing fast, we will get some major backings. The problem is that instead of improving Ruby, Twitter decided to ditch it. Maybe they really didn't have the people Google has when it comes to language builders. Since google app engine runs python it is in direct google interest to make it fast. Once it starts running ruby, vuala! So don't worry, they'll get to it.
Python was released in 1991; Ruby was released in 1995. If Ruby is significantly lagging behind Python at this point, it seems unlikely to make up the difference in the future.
I just did a quick test of 1.9 vs rubinius on the alioth pidigits and btrees benchmarks, and rubinius was 1.5 times as slow on pidigits and twice as slow on btrees. In addition, the release notes state that they are aware that several string operations in Rubinius are currently slower than their MRI 1.8 equivalents.
I'm excited that rubinius is out, but I'm not sure at the moment what it's advantages are versus MRI in terms of practical use.
This seems pretty accurate given the kind of performance we've seen thus far. One thing to understand about Rubinius is that we've optimized it to the hilt for running Ruby code. So when you see Rubinius performing, say, 1.5x slower than MRI on a particular String method, what you're seeing is Rubinius running ruby at 1.5x slower than C code. If you compare Rubinius to MRI both running pure ruby code, you'll see Rubinius shine. It's getting the performance of the methods that MRI implements in C that we still have work to do on. This is part of the strategy of the project, because it means that we're improving the performance of all ruby code, thus raising the bar not for just one method but for the whole program.
This is perhaps a silly question, but now that you have a solid base of ruby-in-ruby is there any room to re-optimize certain critical sections (hashes, sockets...) in C? Perhaps using a custom API that preserves most or all of the flexibility that is Rubinius's hallmark?
I presume that since you still support most compiled gems that linking to C code is still possible. Just wondering if there might be a best-of-both-worlds solution out there.
We already done that, optimize out certain things into primitives, which are implemented in C++.
We support as subset of the MRI extension API, mainly we don't support anything using RBASIC(), RHASH(), or RREGXP() because those expose raw C data structures and we don't use the same data structures as MRI.
Aren't String and Array a mix of both C++ and Ruby, though? So it's a bit more like saying it's running that mix of C++ and Ruby 1.5x slower than MRI runs C, for varying percentages of Ruby and C++.
For pure ruby code you write yourself with your own classes and while loops and algorithms and whatnot, rubinius can be up to 20 times faster then MRI. But there are still some corner cases where it is slower. So micro benchmarks rubinius kicks ass over almost all the rubies. But macro is still has some spots to polish.
The reason for this is that core things like Hash and String and Array are written in pure ruby. And they are only like 1.5 times slower then the C impls in the other rubies. This means that it is optimized for running ruby code really fast, this means that once the edge cases are gone, rubinius will smoke all the other rubies hands down.
I've had ruby aliased to rbx on my own personal laptop and run all of my development on rbx, I only have to bust out MRI every once in a while, like once a month. I write lots of code with event machine, redis, amqp and many other complex parts of ruby ecosystem and for the most part they all just work on rbx.
Huge congrats to rubinius team again, I predict this will be the default ruby for most people inside of a year if not 6 months.
Rubinius is ruby done right IMHO.