I'll take a look at the benchmarks again (it's been a while)
I know getting a JVM dynlang to compete with the native impl times
from the command line is not going to happen without outside
intervention, just thought it was interesting to see the numbers
compared to other languages on the JVM.
That sux about the classloader slowdown (AOT ruby compile).
improvement in times with -J-Xverify:none (adding -C didn't really
make a difference)
went from: 0m1.668s
to: 0m1.268s
-J-Djruby.reflection=true option causes NPE for me
Exception in thread "main" java.lang.NullPointerException
at org.jruby.RubyModule.defineAnnotatedMethod(RubyModule.java:511)
at org.jruby.RubyModule.defineAnnotatedMethods(RubyModule.java:458)
at org.jruby.RubyKernel.createKernelModule(RubyKernel.java:84)
at org.jruby.Ruby.initCoreClasses(Ruby.java:1279)
at org.jruby.Ruby.init(Ruby.java:1171)
at org.jruby.Ruby.newInstance(Ruby.java:322)
at org.jruby.Main.runInterpreter(Main.java:168)
at org.jruby.Main.run(Main.java:117)
at org.jruby.Main.main(Main.java:92)
Too tired to look into why right now...
M
On Nov 26, 2007 2:07 AM, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote:
> Mike McKinney wrote:
> > Was goofing around, decided to write a blog post about how different
> > languages do the same thing (read and spit out file contents)... blog
> > post here:
> > http://huikau.com/2007/11/25/simple-file-io-in-different-dynamic-languages/
> >
> > I got curious about the JVM impls, timed them and figured I would
> > share the results with this list:
> > lang real time lang ver
> >
> > RHINO: 0m0.310s (1.6R2)
> > GROOVY: 0m0.885s (1.0)
> > SCALA: 0m1.312s (2.6.0)
> > JRUBY: 0m1.668s (1.1b1)
> >
> > Not the most controlled test, just used built-in 'time' for Mac OS
> > X... (i.e. time jruby fileTest.rb) This doesn't isolate the file IO
> > from the environment setup... but to a new user, this time counts.
> > (time spent waiting for your command line to return control.) Simply
> > running: jruby -e "a='a'" is only slightly faster if at all!
>
> So you're measuring total execution time including startup for a small
> file? If so, then these numbers are not too surprising.
>
> > I have questions:
> > 1. does the overall warm-up time for JRuby include loading actual .rb files?
>
> It includes everything, from loading .rb files to compiling the script
> on the command line to binding all methods on all Ruby classes (by
> generating small stub classes for each method) to actual execution.
>
> > 2. is there a plan to compile all Ruby .rb files and stick them in a
> > jar for possible performance boost?
>
> At the moment, this doesn't appear to give much of a performance boost
> at startup, since class loading/verification ends up actually being
> *slower* than just parsing the .rb file. We're fighting an uphill battle
> against the verifier here.
>
> > 3. while we're at it... how about compiling all Gems to jars?
> > (command line option?) I swear I heard this idea floating around
> > somewhere...
>
> Also considered, but unlikely to improve startup time; if we support it,
> it would be to reduce the time until gem code JITs in-memory, since the
> majority of it would already be compiled. It would reduce warm-up time
> but not startup time.
>
> > 4. since I know my tests were not very scientific by any stretch...
> > what are some opinions on how to gather this type of data (speed,
> > determining JVM startup vs. environment load, etc.)
>
> If you're interested in IO performance, put time measurements into the
> script itself; that will exclude startup time. If you're interested in
> startup time, we have a number of benchmarks included in JRuby that
> basically spin up the basic runtime; actual startup will be that plus
> the cost of loading user code (which should usually be fairly small, or
> at least comparable to C Ruby).
>
> > Rhino's numbers from the command line may not be attainable due to the
> > scope of the language... but it's something to strive for.
>
> If this is Rhino in interpreted mode, that's probably why startup is so
> much better. You may try some of the following options to JRuby to
> improve startup time, and please report your results.
>
> -J-Xverify:none (disable class verification, not recommended for real apps)
> -J-Djruby.reflection=true (disable code-generated method bindings)
> -C disable all compilation
>
> We are aware of the startup speed issue, and we'd love to find a good
> answer. But the goals of fast long-term execution and fast startup are
> at cross purposes on current JVM implementations. So it's a tricky problem.
>
> - Charlie
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
