21–30 of 79 posts
10-30% faster is “massive”? Ruby standard is 5-30 times slower than all other popular language implementations, I'd expect at least a 100% increase to be considered “massive.” I'd call this just “a speed boost.” Anyway, keep it up.
"Compared to JRuby on Java 6, JRuby on Java 7 without invokedynamic is around 25% faster, and JRuby with invokedynamic is nearly 3 times faster."
Anyone done any comparisons between this and the official (MRI/KRI/YARV) 1.9.2 or 1.9.3?
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 i…
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.
I have not got round to playing with JRuby but if you can squeeze 10-30% extra performance then I am keen!
Being able to write classes in Java (or Mirah) where speed is crucial, and use them from within JRuby without having to do any additional work, is a nice bonus as well.
The only downside is startup time, but that's been improving a lot recently.
Earlier quoted context omitted.
I obviously have, but I have a lot of respect for the MRI folks and usually don't publish those results. You're free to try it out yourself. In general, JRuby should be significantly faster than MRI 1.9.2 or 1.9.3 for running Ruby code, and usually faster inside the core classes (String, Array, etc). If it's not, I consider it a bug, and encourage bug reports to that effect.
Until recently I dismissed JRuby, but then I needed to run some stress testing code against an Oracle DB. With MRI Ruby and the OCI8 library, the Ruby overhead stopped me being able to push the database hard enough. I switched to JRuby and JDBC and the results were amazing, so I am converted. The only niggle I have is the startup overhead, which I know is a JVM thing. Not a problem for my benchmarking, but a little b…
Anyone done any comparisons between this and the official (MRI/KRI/YARV) 1.9.2 or 1.9.3?
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 i…
Anyone done any comparisons between this and the official (MRI/KRI/YARV) 1.9.2 or 1.9.3?
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 i…
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.
10-30% faster is “massive”? Ruby standard is 5-30 times slower than all other popular language implementations, I'd expect at least a 100% increase to be considered “massive.” I'd call this just “a speed boost.” Anyway, keep it up.
I have not got round to playing with JRuby but if you can squeeze 10-30% extra performance then I am keen!
I'm a big fan of JRuby for two notable reasons. First, JRuby runs on the JVM, which is arguably the most mature and tested VM on the market today; second, you can leverage both the Ruby and Java ecosystems without any additional overhead (the Java interop is almost seamless). Being able to write classes in Java (or Mirah) where speed is crucial, and use them from within JRuby without having to do any additional work,…
Anyone done any comparisons between this and the official (MRI/KRI/YARV) 1.9.2 or 1.9.3?
I obviously have, but I have a lot of respect for the MRI folks and usually don't publish those results. You're free to try it out yourself. In general, JRuby should be significantly faster than MRI 1.9.2 or 1.9.3 for running Ruby code, and usually faster inside the core classes (String, Array, etc). If it's not, I consider it a bug, and encourage bug reports to that effect.
Earlier quoted context omitted.
I obviously have, but I have a lot of respect for the MRI folks and usually don't publish those results. You're free to try it out yourself. In general, JRuby should be significantly faster than MRI 1.9.2 or 1.9.3 for running Ruby code, and usually faster inside the core classes (String, Array, etc). If it's not, I consider it a bug, and encourage bug reports to that effect.
Why would respect for the MRI devs stop you from publishing benchmarks? It's not an insult to say that something else is faster. I'd imagine the competition might drive them to improve if at all possible.