If Ruby can get faster than Python sooner, I'd switch focus to Ruby (and somewhat make Go less of a priority for us).
It is actually possible to completely remove the overhead of method-missing.
They're hitting 35x in some benchmarks [2]. Most benefits being in workloads where Ruby has to continuously talk to C; the result-passing part gets compiled away.
It is available in Java 9, if I'm not mistaken. LLVM IR bytecode ingestion is in preparations too [3].
[1] https://youtu.be/b1NTaVQPt1E?t=48m17s [2] http://jruby.org/bench9000/ [3] https://github.com/graalvm/sulong
In fact, a tracing jit could even make the method_missing case fast by automatically specialising and optimizing missing coupled with a vtable/dispatch table.
My forever-in-progress ahead-of-time Ruby compiler uses vtable based dispatch for every method name that's seen in the program at least once, and that's usually most of them (unless people e.g. construct method names dynamically at runtime).
To handle method_missing, it creates thunks for each method name and fills the missing vtable slots with those, which is similar to what I suggest above - the next step of dynamically optimising method_missing for called symbols and replacing the vtable thunks would be a relatively minor step in a JIT.
I don't think anyone expects Ruby to get dramatically faster in the very short term, but there's lots of opportunity to make most Ruby code much faster in the medium term.
I think we'll also start seeing implementations that do things like JIT influence how people write Ruby, because a lot of things won't matter much for MRI performance but will be a huge deal for implementations that uses compilation techniques, so it's possible to get a lot more "compiler-friendly" Ruby while still writing clean Ruby that runs well on other implementations.
e.g. the above "define_method on method_missing" basically boils down to (pseudo code):
def method_missing sym, *args
raise suitable exception if sym doesn't meet right criteria
define_method(sym, args...) do
... whatever ..
end
send(sym,*args)
end
Other Ruby implementations suffer from not being compatible with the MRI ecosystem, you have to port them over. In theory because they're the same language, gems would be easily portable, but the sheer amount of combinatorial work involved means they slowly accrete into separate ecosystems. It's relatively easy to port a gem over and maintain it, but if you don't keep doing it, they'll become incompatible.
MRI has the largest install base, and the biggest gem library, and the largest number of eyes on it. Sure, JRuby and Rubinius are faster, but Ruby was never a language chosen for speed, so most devs reach for MRI first and then only branch out when requirements force them out.
For me, the differences between MRI and other implementations effectively make them different languages, I'd jump to Elixir before giving JRuby a shot. I have a sense that other Rubies, except maybe Opal, will always be niche.
So, yes, on the surface of it, this particular Ruby build might appeal to people looking for performance.
But from a language research position it is interesting to decouple concepts like GC from the language so that they can be studied and optimized as a pattern and then be potentially reapplied to any language runtime.
I agree that some concepts might be pulled into MRI Ruby 3, but OMR may be a powerful testbed for language researchers to debate GC strategies and measure effects in various languages before committing to a single language integration.
The reality of JRuby startup times make it not a good fit for scripting tasks but otherwise server and threaded tasks are a great fit. Since using JRuby more recently I feel the ecosystem support is probably the best of the non-MRIs. I rarely run into compatibility issues. Conversely JRuby's Java integration has been a very useful feature that no other Ruby implementation offers.
Wha? Sorry but this sounds pretty FUDdish. I have never had an issue with JRuby to the extent that you are describing. Do you have some examples?
I know of many large app deployments in JRuby at large household name companies.
The only thing JRuby doesnt have is the relatively niche CExt functions.
I have considered it deeply. Many of our enterprise systems are Java-based, so JRuby's ability to call Java methods directly without implanting services would be a huge pragmatic boon. But every time I consider that I have to balance it against being able to use a constellation of gems in Rails. For example, nokogiri (libxml) is used in a ton of stuff. Sure there are Java equivalents, but that isn't the issue. Rather I would have to reimplement or find replacements for everything we use that depends on that without introducing side-effects. In my experience that's really hard unless it's a toy application without many dependencies. (Read: opposite of most enterprise Ruby apps)
Also, as a gem author I've tried to support jruby along with MRI, but it requires jumping through a lot more hoops. Of course any cross-platform code requires more work to support, but it's a pressure on small devs. If no one needs it, no one helps support it, so then it becomes another gem that is effectively MRI-only. Kind of a viscous cycle.
Ruby also suffers from the lack of a formal VM, so other implementations are merely similar rather than being guaranteed to run all programs. This is not the same with JVM vendors, where choice of IBM vs Oracle is largely based on extrinsic features rather than intrinsic compatibility. (Or at least you have to get in really deep to find differences-- in Rails you usually find incompatibilities that stop you from even starting the app).
The deal breaker for me is the very slow startup time for tests and no gains for run once scripts. I've seen people developing with MRI and doing CI on JRuby to work around that. It's worth doing that only if you have a service running with some real load. Most internal services do nothing almost all the time.
Still a ways to to go, but we've built out a reasonable foundation to start with.
[1]: http://www.slideshare.net/MatthewGaudet/experiments-in-shari...
Once that's stable, then I'd like to focus on trying to some of this code integrated into MRI upstream, perhaps as an experimental branch for the 2.5 development cycle, or as something that can be compiled in optionally.
In parallel, I'd like to work on improving performance . We've not put a lot of effort into performance, and have instead focused on compatibility and currency, so that we have a good base from which to grow performance on top of.
In my mind, I look at Truffle and Graal as a potential way forward to build new high performance JVM languages.
OMR I see as a way to build language runtimes in C/C++, and have a production pedigree.
What does OMR stand for?
<something><something>runtime?
Original definition was 'Open Managed Runtimes', but we can do more than just managed runtimes with OMR technology, and so that seemed to sell it short.
If I had to guess at it:
Open Meta-Runtime
But I could see how that might be misinterpreted compared to their goals. Not all cap names are acronyms?
The irony.
But in all seriousness, this is awesome.
You can follow the work in progress on trunk (what will become Ruby 2.4 in December) here: https://github.com/rubyomr-preview/ruby/tree/ruby_2_4_omr_pr...