From a 10,000 foot view, the changes to jruby since 1.1.6 improved
the benchmark results by around 20%. Using the --server and --fast
switches gave an overall improvement of around 45%. The tests were
run with jruby 1.1.6 release and the jruby-trunk as of March 19 2009.
A few weeks ago I ran these tests under MRI (with the C json gem) but
I didn’t save the results. Suffice it to say that jruby destroyed MRI
in that test by around 35% (though memory usage was much higher under
jruby, like 2GB (jruby) versus 500MB (MRI)).
Jruby is getting seriously fast for my uses. I tested this on the 32-
bit Java5 VM under OSX Intel. I know from prior benchmarks that
running the 64-bit Java6 VM provides an absolute improvement of around
another 10% with server mode boosting that to 15%. YMMV.
Many many many thanks to Charles, Tom, Nick and the cast of hundreds
who have been making such steady progress on our favorite ruby
implementation!
Those are great numbers! Can you also do a run of the numbers with
–server under JRuby 1.1.6? Then we can compare apples to apples all the
way through.
I’m hoping for 1.3 to make --fast a real production option, and we also
have a bunch of optimization ideas that may finally put JRuby way out in
front as far as Ruby performance goes. It would be nice to convincingly
“win” the benchmarks game so we can put that to bed for a while.
Chuck R. wrote:
From a 10,000 foot view, the changes to jruby since 1.1.6 improved the
32-bit Java5 VM under OSX Intel. I know from prior benchmarks that
To unsubscribe from this list, please visit:
I’ll do another run through on Monday with --server and jruby 1.1.6.
For kicks, I’ll also run everything under Java6 64-bit since running
this stuff is pretty much fire-and-forget anyway.
I’ll post 'em Tuesday.
cr
On Mar 20, 2009, at 6:21 PM, Charles Oliver N. wrote:
Chuck R. wrote:
A few weeks ago I ran these tests under MRI (with the C json gem)
but I didn’t save the results. Suffice it to say that jruby
destroyed MRI in that test by around 35% (though memory usage was
much higher under jruby, like 2GB (jruby) versus 500MB (MRI)).
Jruby is getting seriously fast for my uses. I tested this on the
32-bit Java5 VM under OSX Intel. I know from prior benchmarks that
running the 64-bit Java6 VM provides an absolute improvement of
around another 10% with server mode boosting that to 15%. YMMV.
Many many many thanks to Charles, Tom, Nick and the cast of
hundreds who have been making such steady progress on our favorite
ruby implementation!
Jruby is getting seriously fast for my uses. I tested this on the
32-bit Java5 VM under OSX Intel. I know from prior benchmarks that
running the 64-bit Java6 VM provides an absolute improvement of around
another 10% with server mode boosting that to 15%. YMMV.
It’s probably worth mentioning that we also did no major architectural
work to improve performance in 1.2. Almost all improvements were solely
from “cleanup” work that just reduced overhead of the code we already
had. The exception would be --fast, which has existed for a while, but
which had a number of major changes to make it “safer” for real Ruby
code.
I’m planning to do some larger architectural changes for 1.3 that will
hopefully produce much more significant performance boosts across the
board.
Those are great numbers! Can you also do a run of the numbers with
–server under JRuby 1.1.6? Then we can compare apples to apples
all the way through.
I’m hoping for 1.3 to make --fast a real production option, and we
also have a bunch of optimization ideas that may finally put JRuby
way out in front as far as Ruby performance goes. It would be nice
to convincingly “win” the benchmarks game so we can put that to bed
for a while.
I reran the benchmarks using the 64-bit Java6 VM under OSX 10.5.6.
Here are the results in separate pasties so you can put the windows
side-by-side for comparison.
Clearly the --server switch improves overall performance. The --fast
switch also gives a nice boost on top of it. If you can run your code
with that switch and it remains stable, go for it.
It’s hard to believe that these performance improvements are all from
a little bit of code cleanup. Whatever the reality, jruby is wicked
fast.
cr
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.