More performance explorations

Charles Oliver Nutter headius at headius.com
Thu Jun 2 09:01:43 PDT 2011 

Ok, the ricochet flag performs in the expected range...but still
slower than the old logic, and also slower than the 5/13 macosx build.

~/projects/jruby ➔ jruby -X+C
-J-Djava.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=false --server
bench/bench_fib_recursive.rb 5 35
9227465
  1.354000   0.000000   1.354000 (  1.249000)
9227465
  0.962000   0.000000   0.962000 (  0.962000)
9227465
  0.953000   0.000000   0.953000 (  0.953000)
9227465
  0.953000   0.000000   0.953000 (  0.954000)
9227465
  0.958000   0.000000   0.958000 (  0.958000)

~/projects/jruby ➔ jruby -X+C
-J-Djava.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=true --server
bench/bench_fib_recursive.rb 5 35
9227465
  1.316000   0.000000   1.316000 (  1.264000)
9227465
  1.001000   0.000000   1.001000 (  1.001000)
9227465
  1.010000   0.000000   1.010000 (  1.011000)
9227465
  0.999000   0.000000   0.999000 (  1.000000)
9227465
  1.008000   0.000000   1.008000 (  1.008000)

~/projects/jruby ➔ pickjdk 2
New JDK: 1.7.0.jdk

~/projects/jruby ➔ jruby -X+C --server bench/bench_fib_recursive.rb 5 359227465
  1.127000   0.000000   1.127000 (  0.940000)
9227465
  0.810000   0.000000   0.810000 (  0.810000)
9227465
  0.809000   0.000000   0.809000 (  0.809000)
9227465
  0.810000   0.000000   0.810000 (  0.810000)
9227465
  0.822000   0.000000   0.822000 (  0.822000)

The last result is the 5/13 build.

Another angle: fib with Float (a boxed double, basically):

~/projects/jruby ➔ jruby -X+C
-J-Djava.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=true --server
bench/bench_fib_float_recursive.rb 5 35
9227465.0
  2.492000   0.000000   2.492000 (  2.437000)
9227465.0
  1.951000   0.000000   1.951000 (  1.951000)
9227465.0
  1.950000   0.000000   1.950000 (  1.950000)
9227465.0
  1.951000   0.000000   1.951000 (  1.952000)
^C
~/projects/jruby ➔ jruby -X+C
-J-Djava.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=false --server
bench/bench_fib_float_recursive.rb 5 35
9227465.0
  2.369000   0.000000   2.369000 (  2.324000)
9227465.0
  1.916000   0.000000   1.916000 (  1.916000)
9227465.0
  1.904000   0.000000   1.904000 (  1.904000)
9227465.0
  1.905000   0.000000   1.905000 (  1.905000)
9227465.0
  1.924000   0.000000   1.924000 (  1.924000)

~/projects/jruby ➔ pickjdk 2New JDK: 1.7.0.jdk

~/projects/jruby ➔ jruby -X+C --server
bench/bench_fib_float_recursive.rb 5 359227465.0
  2.110000   0.000000   2.110000 (  2.055000)
9227465.0
  1.690000   0.000000   1.690000 (  1.690000)
9227465.0
  1.718000   0.000000   1.718000 (  1.718000)
9227465.0
  1.721000   0.000000   1.721000 (  1.721000)

I'm on leave right now so I can't spend a lot of time investigating
this until perhaps Monday.

- Charlie

On Thu, Jun 2, 2011 at 10:23 AM, Charles Oliver Nutter
<headius at headius.com> wrote:
> I tentatively admit guilt. I was still running off the 5/26 build,
> which still had convertArguments and probably didn't have all the
> recent optimizations for ricochet. I'm doing an updated build now and
> will report back shortly.
>
> On Thu, Jun 2, 2011 at 10:13 AM, Charles Oliver Nutter
> <headius at headius.com> wrote:
>> Ok, I'll reinvestigate; I thought I had logged that it was compiling
>> but perhaps that wasn't with the new property...
>>
>> On Wed, Jun 1, 2011 at 3:37 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>>> I'm seeing slow perf as well but I think it might be a jruby/292 mismatch problem:
>>>
>>> Exception <a 'java/lang/NoSuchMethodError'>: java.lang.invoke.MethodHandles.convertArguments(Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodT\
>>> ype;)Ljava/lang/invoke/MethodHandle; (0xefdd4b18 )
>>> thrown [/net/smite.us.oracle.com/export/ws/bim/src/share/vm/interpreter/linkResolver.cpp, line 354]
>>> for thread 0x0807c800
>>> Exception <a 'java/lang/NoSuchMethodError'> (0xefdd4b18)
>>>  thrown in interpreter method <{method} '<clinit>' '()V' in 'org/jruby/runtime/invokedynamic/InvokeDynamicSupport'>
>>>  at bci 2876 for thread 0x0807c800
>>> Exception <a 'java/lang/NoSuchMethodError'> (0xefdd4b18 )
>>>
>>> which results in this:
>>>
>>> Exception <a 'java/lang/NoSuchMethodError'> (0xefdd4b18)
>>>  thrown in interpreter method <{method} 'tryCompile' '(Lorg/jruby/ast/Node;Ljava/lang/String;Lorg/jruby/util/JRubyClassLoader;Lorg>
>>>  at bci 56 for thread 0x0807c800
>>> Exception <a 'java/lang/NoClassDefFoundError'>: Could not initialize class org.jruby.compiler.impl.StandardASMCompiler (0xefe4c818 )
>>> thrown [/net/smite.us.oracle.com/export/ws/bim/src/share/vm/oops/instanceKlass.cpp, line 440]
>>> for thread 0x0807c800
>>> Exception <a 'java/lang/NoClassDefFoundError'> (0xefe4c818)
>>>  thrown in interpreter method <{method} '<init>' '(Ljava/lang/String;Ljava/lang/String;Lorg/jruby/Ruby;Lorg/jruby/internal/runtime>
>>>  at bci 126 for thread 0x0807c800
>>> Exception <a 'java/lang/NoClassDefFoundError'> (0xefe4c818)
>>>  thrown in interpreter method <{method} 'jitThresholdReached' '(Lorg/jruby/internal/runtime/methods/DefaultMethod;Lorg/jruby/RubyI>
>>>  at bci 220 for thread 0x0807c800
>>>
>>> So I think the jruby compiler never triggers with the new meth.jar.
>>>
>>> tom
>>>
>>> On May 31, 2011, at 12:03 PM, John Rose wrote:
>>>
>>>> On May 31, 2011, at 9:36 AM, Charles Oliver Nutter wrote:
>>>>
>>>>> If you mean java.lang.invoke.GWT_FORCE_RICOCHET_FRAMES=true, then I
>>>>> have more bad news...it's even slower :(
>>>>
>>>> Is that with meth-bim.patch applied?  That is Tom's first cut at an optimization for RFs.
>>>>
>>>> -- John
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>
>

More information about the mlvm-dev mailing list