That's great then! I will try to inokedynamicize my code soon to see what I could gain ;)
Herve Sent from my iPhone On 11 juil. 2011, at 15:36, Rémi Forax <fo...@univ-mlv.fr> wrote: > On 07/11/2011 03:34 PM, Hervé Girod wrote: >> Hello, >> >> My comprehension is that the lookup can be performed only once, to get the >> MethodHandle, and that checks are done there and not after when using the >> MethodHandle anymore. Am I right? > > Yes ! > > Rémi > >> Sent from my iPhone >> >> On 11 juil. 2011, at 15:17, Christian >> Thalinger<christian.thalin...@oracle.com> wrote: >> >>> On Jul 9, 2011, at 3:27 PM, Hiroshi Nakamura wrote: >>>> Hello, >>>> >>>> Thanks for you comments. >>>> >>>> On Sat, Jul 9, 2011 at 19:01, Jochen Theodorou<blackd...@gmx.org> wrote: >>>>>> Code is here: >>>>>> https://raw.github.com/nahi/jsr292-sandbox/master/src/jp/gr/java_conf/jruby/MethodHandleTest.java >>>>> lookup I don't know. I am not sure about the recent versions, I think >>>>> the lookup is using the same "core" as Reflection plus additional >>>>> checks. I don't expect that to be faster. It would be very nice though. >>>>> >>>>> The performance of the invocation cannot be meassured like you do it I >>>>> think. The big pro comes from the ability to inline the method calls, >>>>> but this is only present if you use the invokedynamic bytecode >>>>> instruction. There is currently no way in Java to express invokedynamic. >>>> Sure. I should have written it clearly. I heard from someone at Java >>>> SE 7 launch event that reflection would get faster on Java SE 7 even >>>> if you don't use dynamic language, so I wanted to measure the >>>> MethodHandle perf without invokedynamic. >>>> >>>> For invokedynamic, I did some (bogus, experimental, micro)benchmark >>>> with current JRuby. >>>> http://bit.ly/invokedynamic (Flash, Japanese) >>>> Please see the circle at the right edge of 5 circles. Invokedynamic >>>> support of JRuby is still experimental but it already outperforms >>>> existing optimization code for some microbenchmarks. Great job, >>>> Charles. >>> Just a quick follow up on the tak numbers, which look really bad. The >>> problem here is that we inline the fallback path (a bug we know about). >>> Excluding that one method from inlining actually gives better numbers with >>> invokedynamic: >>> >>> intelsdv03.us.oracle.com:/export/twisti/jruby$ jruby -X+C --server >>> bench/bench_tak.rb 5 >>> user system total real >>> 1.300000 0.000000 1.300000 ( 1.263000) >>> 1.018000 0.000000 1.018000 ( 1.018000) >>> 1.018000 0.000000 1.018000 ( 1.018000) >>> 1.027000 0.000000 1.027000 ( 1.027000) >>> 1.024000 0.000000 1.024000 ( 1.023000) >>> >>> intelsdv03.us.oracle.com:/export/twisti/jruby$ jruby -X+C --server >>> -J-XX:CompileCommand=dontinline,*.invocationFallback bench/bench_tak.rb 5 >>> CompilerOracle: dontinline *.invocationFallback >>> user system total real >>> 0.619000 0.000000 0.619000 ( 0.580000) >>> 0.422000 0.000000 0.422000 ( 0.422000) >>> 0.422000 0.000000 0.422000 ( 0.422000) >>> 0.422000 0.000000 0.422000 ( 0.422000) >>> 0.422000 0.000000 0.422000 ( 0.422000) >>> >>> intelsdv03.us.oracle.com:/export/twisti/jruby$ jruby -X+C --server >>> -Xcompile.invokedynamic=false bench/bench_tak.rb 5 >>> user system total real >>> 0.824000 0.000000 0.824000 ( 0.788000) >>> 0.565000 0.000000 0.565000 ( 0.565000) >>> 0.565000 0.000000 0.565000 ( 0.565000) >>> 0.565000 0.000000 0.565000 ( 0.565000) >>> 0.565000 0.000000 0.565000 ( 0.565000) >>> >>> -- Christian >>> >>>> Disclaimer: I'm one of a JRuby committer :) >>>> >>>>> And a third point... even if there where invokedynamic used, I think in >>>>> your case it would not really bring forth the real performance >>>>> possibilities, since your receiver is changing all the time. >>>> Sure. JRuby's current invokedynamic code checks receiver type with the >>>> test for guardWithTest if I understand correctly. Invokedynamic would >>>> not bring perf gain for my sample MethodHandleTest, but if naive >>>> MethodHandle invocation is slower than reflection, invokedynamic might >>>> be the way I thought. >>>> >>>>> But in general I must say, I would have expected the performance to be >>>>> at least near Reflection as well. I mean the situation is for Reflection >>>>> not all that better. >>>> Agreed. I won't expect it to Java SE 7 GA though. >>>> >>>> Regards, >>>> // NaHi >>>> _______________________________________________ >>>> mlvm-dev mailing list >>>> mlvm-dev@openjdk.java.net >>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev@openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
