On Jul 7, 2011, at 8:52 AM, Christian Thalinger wrote: > On Jul 6, 2011, at 10:49 PM, Tom Rodriguez wrote: >> >> On Jul 6, 2011, at 4:18 AM, Christian Thalinger wrote: >> >>> On Jul 5, 2011, at 6:39 PM, Charles Oliver Nutter wrote: >>>> I'm not in position at this exact moment to report perf issues, but >>>> Rémi's list would be a good start. I'll return to JRuby benchmarks and >>>> start looking for specific bottlenecks. >>> >>> OK. >>> >>>> >>>> As reported in some of my my previous emails, JRuby has several uses >>>> of indy that are off by default, so it will be nice to start getting >>>> them enabled. >>> >>> When I use -Xinvokedynamic.all=true with bench_string_ops.rb I get: >>> >>> InvokeDynamicSupport.java:710:in `fixnum_op_mul': >>> java.lang.ClassCastException: org.jruby.RubyString cannot be cast to >>> org.jruby.RubyFixnum >>> >>> I just saw a benchmark I haven't seen before: bench_avi_base64.rb >>> >>> Performance with indy is not very good: >>> >>> intelsdv07:~/mlvm/jruby$ jruby --server -Xcompile.invokedynamic=false >>> bench/bench_avi_base64.rb >>> 1.569000 0.000000 1.569000 ( 1.539000) >>> 0.895000 0.000000 0.895000 ( 0.895000) >>> 0.850000 0.000000 0.850000 ( 0.850000) >>> 0.848000 0.000000 0.848000 ( 0.848000) >>> 0.848000 0.000000 0.848000 ( 0.848000) >>> >>> intelsdv07:~/mlvm/jruby$ jruby --server bench/bench_avi_base64.rb >>> 2.335000 0.000000 2.335000 ( 2.305000) >>> 1.503000 0.000000 1.503000 ( 1.503000) >>> 1.470000 0.000000 1.470000 ( 1.470000) >>> 1.479000 0.000000 1.479000 ( 1.479000) >>> 1.470000 0.000000 1.470000 ( 1.470000) >>> >>> The pattern I always see when I look at the inlining tree of a badly >>> performing benchmark is this one: >>> >>> @ 9 >>> org.jruby.runtime.invokedynamic.InvokeDynamicSupport::invocationFallback >>> (197 bytes) inline (hot) >> >> I would think we don't want this inlined since it's the fallback path. Try >> -XX:CompileCommand=dontinline,*,invocationFallback. Inlining it may cause >> us to run up against other limits like the NodeInliningCutoff and >> DesiredMethodLimit. > > Ahh, right. This is inlined because of how we promote the invocation count > of the call site into the method handle chain. Sorry, I forgot.
Hmm, now I'm confused. Excluding the method from compilation helps a bit: intelsdv07:~/mlvm/jruby$ jruby --server -J-XX:CompileCommand=dontinline,*.invocationFallback bench/bench_avi_base64.rb CompilerOracle: dontinline *.invocationFallback 1.941000 0.000000 1.941000 ( 1.869000) 1.081000 0.000000 1.081000 ( 1.081000) 1.045000 0.000000 1.045000 ( 1.045000) 1.040000 0.000000 1.040000 ( 1.041000) 1.044000 0.000000 1.044000 ( 1.044000) But then I tried -X+C: intelsdv07:~/mlvm/jruby$ jruby -X+C --server -Xcompile.invokedynamic=false bench/bench_avi_base64.rb 1.512000 0.000000 1.512000 ( 1.484000) 0.892000 0.000000 0.892000 ( 0.892000) 0.845000 0.000000 0.845000 ( 0.846000) 0.840000 0.000000 0.840000 ( 0.840000) 0.844000 0.000000 0.844000 ( 0.844000) intelsdv07:~/mlvm/jruby$ jruby -X+C --server -J-XX:CompileCommand=dontinline,*.invocationFallback bench/bench_avi_base64.rb CompilerOracle: dontinline *.invocationFallback 1.477000 0.000000 1.477000 ( 1.447000) 0.794000 0.000000 0.794000 ( 0.794000) 0.745000 0.000000 0.745000 ( 0.745000) 0.741000 0.000000 0.741000 ( 0.741000) 0.744000 0.000000 0.744000 ( 0.744000) intelsdv07:~/mlvm/jruby$ jruby -X+C --server bench/bench_avi_base64.rb 1.642000 0.000000 1.642000 ( 1.614000) 0.808000 0.000000 0.808000 ( 0.808000) 0.767000 0.000000 0.767000 ( 0.767000) 0.763000 0.000000 0.763000 ( 0.763000) 0.769000 0.000000 0.769000 ( 0.770000) So what is -X+C actually doing? The helps states: -X+C force compilation of all scripts before they are run (except eval) But I supposed that all hot scripts are compiled in JRuby in the end anyway. Is that wrong? -- Christian _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
