At 1:14 PM -0600 12/15/09, Charles Oliver N. wrote:
from bench_threaded_reverse.rb:77
from bench_threaded_reverse.rb:76:in `times'
from bench_threaded_reverse.rb:76
This one always requires a numeric parameter for the number of threads
to use. It’s an odd benchmark.
OK, running 4 threads on my 2.5 GHz Intel Core Duo 2 MacBook Pro JRuby
and MagLev are much faster then the other VMs:
[I don’t know how to interpret the cases where the user time is more
than the real time ??]
$ time jruby bench_threaded_reverse.rb 4
real 0m14.076s
user 0m21.300s
sys 0m1.139s
$ time maglev-ruby bench_threaded_reverse.rb 4
real 0m15.453s
user 0m10.599s
sys 0m0.365s
$ time ruby19 bench_threaded_reverse.rb 4
real 0m39.475s
user 0m38.497s
sys 0m0.414s
$ time ruby bench_threaded_reverse.rb 4
real 0m39.744s
user 0m38.867s
sys 0m0.387s
$ time rbx bench_threaded_reverse.rb 4
real 1m20.313s
user 1m14.747s
sys 0m0.722s
$ time macruby bench_threaded_reverse.rb 4
real 1m47.122s
user 2m46.045s
sys 0m19.389s
ruby 6.819144
Yeah, it’s very math-heavy, which is where we’re going to slip behind
without JVM support for fixnums. But there’s also some heavy block use
in there, so if we improve block dispatch performance we’ll be able to
make up some of the gap.
Your numbers do seem a little slow, though…after warmup, my machine
runs the fractal benchmark on JRuby in 1.5s. Are these single runs?
You’re right – I hadn’t realized that the benchmark app took an
argument.
This is better:
$ jruby --version
jruby 1.5.0.dev (ruby 1.8.7 patchlevel 174) (2009-12-12 a4a1bb7) (Java
HotSpot™ 64-Bit Server VM 1.6.0_17) [x86_64-java]
$ jruby bench_fractal.rb 4
Ruby Elapsed 2.540000
Ruby Elapsed 1.935000
Ruby Elapsed 1.891000
Ruby Elapsed 1.816000
$ jruby --fast bench_fractal.rb 4
Ruby Elapsed 2.534000
Ruby Elapsed 1.899000
Ruby Elapsed 1.657000
Ruby Elapsed 1.761000
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email