On my computer
Linux 3.0.0-15-generic #24-Ubuntu SMP Mon Dec 12 15:23:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux RAM=6G
"Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz"
A simple comparison using binary-tree (from computer language benchmark) between ruby1.9.1 and jruby show that on my machine jruby time is half of 1.9.1
~/lang/ruby/jruby-1.6.5/bin$ time ./jruby --server -J-Xmx2000m algo.rb 18 gives
real 0m32.447s
user 0m38.478s
sys 0m0.904s
time ruby1.9.1 algo.rb 18
real 1m11.388s
user 1m11.192s
sys 0m0.148s
./jruby --server -J-Xmx2000m -v
jruby 1.6.5 (ruby-1.8.7-p330) (2011-10-25 9dcd388) (OpenJDK 64-Bit Server VM 1.7.0_147-icedtea) [linux-amd64-java]
the algo.rb file is the version contributed by
# contributed by Jesse Millikan
# Modified by Wesley Moxam and Michael Klaus
this is n=18, for n=16,17 ... results are similar. Half the computing time.
a) There will be problems in the Computer Language Benchmark. Like with the excellent LuaJit, they only allow one version of a language, so a war of implementations to appear would not be surprising.
b) Now that Python is in a difficult transition to Python 3, a strong ruby is a game changing point. Antonio Cangiano
`New Relic Holy Shmoly, Ruby 1.9 smokes Python away!` could be Jruby smokes Python away :) (if there is a two-fold increase in speed I expect A. Cangiano article rewrited)
Duby has become Mirah, and though I have not personally had a lot of time to work on it, it has continued slowly forward. It is basically just Ruby syntax for writing Java, though, so it performs identically to Java.
I don't know the status of Groovy performance in general. I do know that on small numeric benchmarks, JRuby + invokedynamic beats fully-dynamic Groovy, but you can "cheat" and static-type some numeric logic in Groovy, which puts it out in front again.
b) Also Jython is virtually dormant, at some older version of Python, while both JRuby and IronRuby are actively worked on.
c) Groovy hasn't added any support for invokedynamic or even started on it. A month ago they announced they're removing their meta-object protocol rework from the upcoming version 2.0.
SpringSource seem to be repositioning Groovy as a staticly-typed language, this year adding primitive types like in Java. Before everything was an object, and primitives were regarded as leaky abstractions. 2 months ago they employed someone to write a static type checker called "Grumpy" for Groovy, and eventually type inference and optimization, but the work's just started so it might take quite some time depending on how good their new hire is. This year they also tried to rewrite the Antlr 2.7 based parser in Antlr 3.2, using a Google Summer of Code worker, but they didn't get very far. Perhaps the static type checking for Groovy will be more successful, perhaps not.
I imagine this repositioning was instigated by the Grails team wanting a faster language, with dynamicity an optional extra to be used only when required.
I find it a bit of a dodge when a dynamic language has to go to static types for performance. That's not to say I haven't wanted to have that dodge available to JRuby users, but being unable (or unwilling) to unilaterally add optional static types to Ruby, we've been forced to find more creative options. We'll probably never approach Java's raw primitive math performance, but I think we can easily match Java's speed (and in some cases, already do) at manipulating objects.
It also appears that the push toward more static typing in Groovy may come at the cost of dynamicity...or at least incompatible changes in Groovy's dynamic features. Perhaps it's the best move for them, though; they've always pushed Groovy's ability to run (and enhance) plain old Java code, but performance was considerably worse than Java.
It's unfortunate that other JVM dynamic languages did not start exploring invokedynamic sooner. It has been a complete game-changer for JRuby.
Oh, and regarding JRuby versus Python 3...yes, if Ruby 1.9 smokes Python, and JRuby is faster than Ruby 1.9, then JRuby should smoke Python even more. I have not done the comparisons myself, though.
I know some of the implementations there use native libraries that are built into python but only available via RubyGems for Ruby, like numpy. That makes it less of a language shootout (at times) and more of a "who ships the best C libs" shootout.
I believe MRI is generally faster than Python now when they're doing roughly equivalent work in Ruby and Python.
Except that Python has scipy,numpy and cython in its camp. I have spent the last six months of my life making Python code run faster. You can write slow code very quickly in Python. If your users complain about it being too slow you can implement some critical sections in Cython. (again with very minor changes). That being said there is a overhead to calling functions in Python which I would like addressed. (Dictionary lookups were three times as fast as function calls when I measured them).
Your updated Java 7 is probably a 64-bit version. There's currently no Java applet browser plugin for 64-bit (and I'm not sure if there's plans to create one). If you don't mind missing out on Java applets, you'll be fine.
A silly question: Can I call jruby or jirb with something like classpath?
I don't want to lose my java applet for firefox,(ubuntu 11.04 64 bits,four-cores).
I would also like to see some comparison, for example like in the computer benchmark game between jruby and other ruby implementations.
What about clojure and scala? will they get a speed up with the new java 7 update? , Will it be three-fold like jruby (in certain cases?). Thanks for the great work on jruby.
Being more dynamic is great!
$ man update-java-alternatives
--jre
Limit the actions to alternatives belong to a runtime environment, not a development kit.
--jre-headless
Limit the actions to alternatives belong to the headless part of a runtime environment.
--plugin
Limit the actions to alternatives providing browser plugins.
You can certainly just call JRuby directly with the 'java' command, or just set your environment to point at the Java 7 install only when you need it, rather than forcing your whole environment to use Java 7 by default.
I imagine the computer benchmarks game will update when we have a release of JRuby 1.7 out, sometime early 2012. If someone else wants to do some benchmark runs, I have no objection.
As for Clojure and Scala...they may see modest improvements from Java 7, but neither of them use invokedynamic at all. The biggest boost for JRuby comes from invokedynamic.
Perhaps IcedTea (RedHat's fork of OpenJDK) has included a 64-bit plugin. I did not think OpenJDK/OracleJDK had done so yet...but I'd love to be proven wrong.
Like I said, libnpjp2.so is a 64-bit plugin from Sun/Oracle. It's been available from Sun since Java 1.6.0_12 in 2008. It's still available in Java 1.6.0_29; I just downloaded and installed it from Oracle last week. I have not looked into support for Java 7 or operating systems besides linux.
That applies to ARM. I'm not sure of the equivalent workaround for x86_64 outside of installing a 32-bit Java 7 and setting that up as the source of the Java plugin.
A simple comparison using binary-tree (from computer language benchmark) between ruby1.9.1 and jruby show that on my machine jruby time is half of 1.9.1
~/lang/ruby/jruby-1.6.5/bin$ time ./jruby --server -J-Xmx2000m algo.rb 18 gives real 0m32.447s user 0m38.478s sys 0m0.904s
time ruby1.9.1 algo.rb 18 real 1m11.388s user 1m11.192s sys 0m0.148s
./jruby --server -J-Xmx2000m -v jruby 1.6.5 (ruby-1.8.7-p330) (2011-10-25 9dcd388) (OpenJDK 64-Bit Server VM 1.7.0_147-icedtea) [linux-amd64-java]
the algo.rb file is the version contributed by # contributed by Jesse Millikan # Modified by Wesley Moxam and Michael Klaus
this is n=18, for n=16,17 ... results are similar. Half the computing time.