Will Ruby ever see a performance boost as Javascript has seen recently? Can a new VM make it really, really, fast? Or do we have to assume all the benefits of Ruby have an inescapable performance penalty?
What methods could be taken to improve its performance compared to other faster languages?
I think everyone can safely assume it is somewhat slower than other scripting languages
Ruby 1.9 should actually be about the speed of CPython.
Well there's definitely a lot of room for improvement. Here's a list of benchmark times for an N-body simulation (a math-heavy algorithm): http://shootout.alioth.debian.org/u32q/benchmark.php?test=nbody&lang=all
Ruby 1.9 takes 34 minutes whereas one of the faster web-server-friendly language (C#) takes just 37 seconds. So C# is over 50X faster for this particular task. It could be argued that this isn't the type of task that Ruby would be used for anyway. But still there's the question of scalability.
For Ruby to become MUCH faster it really needs to be compiled in some way. This can be in a just-in-time fashion like the V8 Javascript engine. Or it can be done more like ASP.NET which maintains 'cached' compilations behind the scenes. In other words, .NET has the ability to compile on the fly, but in so doing you'll notice that it takes its sweet time. But the payoff is that it doesn't need to re-compile until the code changes and as the benchmark above suggests -- the final compiled code is very fast. So I'd think Ruby (or a variant of it) would be better off copying .NET's technique in this respect.
Jörg W Mittag pointed me in the direction of Rubinius when I asked about Trace Trees finding their way to other scripting languages. Check them out for a faster Ruby.
As an interesting aside, unladen-swallow is trying to speed up Python by using LLVM.
Interesting stuff. There are plenty of unexplored tricks to speed up scripting but I wonder if language developers consider it a priority versus language features and libraries.
Maglev is a ruby implementation that is based upon an existing Smalltalk engine that's been targeting the upper reaches of scaling and usage.
It's designed to be "significantly faster" than existing ruby implementations, you can watch a talk by one of the Maglev Architects if you're interested.
In the same way that different Javascript implementations run faster or slower on different browsers, it's worth noting that ruby itself runs nearly twice as fast on Linux vs Windows.
JRuby has a jrubyc compiler that can create jvm .class files from ruby files. I have never used it, only took a quick look at it, so I don't know how much of Ruby is supported for bytecode compiling. If it is compiled down to bytecode, then the jvm ought to optimize just like any other bytecode.
Yes, Ruby will get significantly faster.
The new Javascript VMs prove that it is possible for an dynamic, weak-typed language which makes significant changes to the execution paths at runtime to be compiled effectively. The LLVM provides a platform-agnostic foundation on which this might happen. These innovations will eventually trickle into all scripting languages.
MacRuby, Maglev, or Rubinius might be first to market with this kind of speed, but the C implementation will probably get there as well.
JRuby, it should be noted, is obsessed with speed and has several "Ruby-like" prototype languages which allow developers to trade certain features for improved performance.
Honestly, the main thing holding Ruby back is that for many, many purposes, it is already fast enough. If you'd like to solve an n-body problem, you should probably look elsewhere. But if you'd like to build a smooth, maintainable web-based application, Ruby will get you into production faster and with great maintainability. And your VCs will be so impressed, they will give you enough money to scale. At which time, you can rewrite your choke points as inline C or Java.
While jRuby often gets clobbered in simple benchmarks, with optional optimizations turned on it starts to look good.
And the official Ruby interpreter is now YARV, although most people haven't experienced it yet because they are still on 1.8.
Yes, Ruby can get faster -- at least to the point where it is no longer an issue.
It will no longer be an issue when it is as fast as any other comparable language. And even then, only if it is equally fast on comparable features.
Why? If it is slower than anything comparable, then there is a way to do it faster, so it is possible. And with the momentum Ruby has, it probably WILL get faster.