"There’s great potential here to bring Ruby performance to native Java or C, but we are just starting the optimization phase of that work. We will do our best to get startup time, memory use, and performance on par with 1.7.x (or better) before the final release of JRuby 9000."
At this point it's conjectural if this implementation Ruby will get there. The headline implies that it's already the case. Hence it's a misleading headline.
It should therefore not be surprising that for carefully crafted benchmarks and with enough time and effort, a Ruby implementation can be as fast as the equivalent Java code. But history is littered with the corpses of implementations that tried and failed to meet its performance goals. (Python's Unladen Swallow being but one example.)
> The performance will be on par _before_ the final release of 9000, the final release should include the big performance boost
I think you misinterpret. It will be on par or better no later than the final (in the not-prerelease sense) release of 9000.
In the 9000 lifecycle (which starts with that final release) there are opportunities to go much further in performance. Essentially, 9000 will be ready for a "full "release when, in addition to feature/stability targets, the performance is at least no worse than the last major stable version. During its stable release lifetime, the performance may get much better (the team sees the opportunity for that, at least.)
the ecosystem is there, I think you're confused... the libraries work, this is the best runtime environment for a Ruby on Rails app.. which is Ruby's killer app..
There are gems that work only with JRuby. There are gems that work with any source-compatible implementation (MRI, JRuby, Rubinius, etc.), there are gems that work with any Ruby which supports the FFI (at least, again, MRI, JRuby, and Rubinius).
There is no implementation (or implementation/platform combination -- MRI on windows supports a different set of gems than MRI on linux) that supports all gems.
That was my point - there are two ecosystems with something shared, but you always need to be aware of the differences.
I think in the future the JVM can offer better integration with native libraries. I'm not familiar with the details, I know JNI was a pain, I know there's JNA and JNR now and I just found this: http://openjdk.java.net/jeps/191
12 comments
[ 237 ms ] story [ 1055 ms ] thread"There’s great potential here to bring Ruby performance to native Java or C, but we are just starting the optimization phase of that work. We will do our best to get startup time, memory use, and performance on par with 1.7.x (or better) before the final release of JRuby 9000."
We know that an implementation of Python can be faster than equivalent code in C, as in the carefully crafted examples of http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-a... or http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-c... .
It should therefore not be surprising that for carefully crafted benchmarks and with enough time and effort, a Ruby implementation can be as fast as the equivalent Java code. But history is littered with the corpses of implementations that tried and failed to meet its performance goals. (Python's Unladen Swallow being but one example.)
I think you misinterpret. It will be on par or better no later than the final (in the not-prerelease sense) release of 9000.
In the 9000 lifecycle (which starts with that final release) there are opportunities to go much further in performance. Essentially, 9000 will be ready for a "full "release when, in addition to feature/stability targets, the performance is at least no worse than the last major stable version. During its stable release lifetime, the performance may get much better (the team sees the opportunity for that, at least.)
There is no implementation (or implementation/platform combination -- MRI on windows supports a different set of gems than MRI on linux) that supports all gems.
I think in the future the JVM can offer better integration with native libraries. I'm not familiar with the details, I know JNI was a pain, I know there's JNA and JNR now and I just found this: http://openjdk.java.net/jeps/191
If anything, it has a stronger overall ecosystem than MRI.