JRuby

Fixnum#== is gets very slow as a boolean OR expression gets longer

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Not A Bug
  • Affects Version/s: JRuby 1.6.5
  • Fix Version/s: None
  • Component/s: Performance
  • Labels:
    None
  • Environment:
    Mac OSX 10.6.x
  • Number of attachments :
    2

Description

I wrote a short benchmark to see if the order of variables and Constants mattered when doing a comparison. It showed that JRuby gets quite slow as a boolean OR expression gets longer which indicates the #== could use a little help. The benchmark and results are enclosed. I compared it to RBX which, while quite a bit slower, doesn't show the steep performance drop-off as the expression gets longer like JRuby does.

Yes, I'm looking for perfection.

After all, this is merely comparing a few integers for cryin' out loud. This should be near native speed (in my dreams).

  1. File
    equals_bench.rb
    14/Dec/11 10:31 PM
    1 kB
    Chuck Remes
  2. File
    out
    14/Dec/11 10:31 PM
    2 kB
    Chuck Remes

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Thomas E Enebo added a comment -

Actually your benchmark measures the cost of us not inlining super. I suspect rbx is inlining the super so the cost of additional compares is much less severe. If you remove the super our numbers get much much lower (screws up first two tests since we don't find). Note that Ruby 1.9.3 is very very similar behavior to us (I suspect for the same reason). In theory, IR will solve this problem since we will be able to inline the super.

Show
Thomas E Enebo added a comment - Actually your benchmark measures the cost of us not inlining super. I suspect rbx is inlining the super so the cost of additional compares is much less severe. If you remove the super our numbers get much much lower (screws up first two tests since we don't find). Note that Ruby 1.9.3 is very very similar behavior to us (I suspect for the same reason). In theory, IR will solve this problem since we will be able to inline the super.
Hide
Permalink
Charles Oliver Nutter added a comment -

As discussed in the Rubinius bug report, this measures just about everything except numeric comparison, which makes up only a tiny fraction of the runtime overhead. The main cost comes from the super invocation and the constant lookups.

On JRuby 1.6.6 on Java 6, performance does slow down as more constants are looked up. However, the slowdown is linear; more constants means more overhead looking them up, and I see no unreasonably degradation.

                                   user     system      total        real
bar1 A in super:               5.999000   0.000000   5.999000 (  6.000000)
bar2 A in super:               5.808000   0.000000   5.808000 (  5.808000)
bar1 C:                        7.633000   0.000000   7.633000 (  7.633000)
bar2 C:                        7.580000   0.000000   7.580000 (  7.580000)
bar1 I:                       11.972000   0.000000  11.972000 ( 11.972000)
bar2 I:                       11.879000   0.000000  11.879000 ( 11.879000)

JRuby 1.7 on Java 7 (using invokedynamic) appears to perform much better and degrade more slowly, likely because constant lookup is nearly free with invokedynamic.

                                   user     system      total        real
bar1 A in super:               5.473000   0.000000   5.473000 (  5.473000)
bar2 A in super:               5.363000   0.000000   5.363000 (  5.363000)
bar1 C:                        6.091000   0.000000   6.091000 (  6.091000)
bar2 C:                        5.952000   0.000000   5.952000 (  5.952000)
bar1 I:                        6.875000   0.000000   6.875000 (  6.875000)
bar2 I:                        7.184000   0.000000   7.184000 (  7.185000)

There is however an unusual perf degradation for JRuby 1.7 on Java 6, which I'll file in a separate bug.

                                   user     system      total        real
bar1 A in super:               7.951000   0.000000   7.951000 (  7.951000)
bar2 A in super:               8.416000   0.000000   8.416000 (  8.416000)
bar1 C:                       11.433000   0.000000  11.433000 ( 11.433000)
bar2 C:                       12.246000   0.000000  12.246000 ( 12.246000)
bar1 I:                       22.286000   0.000000  22.286000 ( 22.286000)
bar2 I:                       23.562000   0.000000  23.562000 ( 23.562000)
Show
Charles Oliver Nutter added a comment - As discussed in the Rubinius bug report, this measures just about everything except numeric comparison, which makes up only a tiny fraction of the runtime overhead. The main cost comes from the super invocation and the constant lookups. On JRuby 1.6.6 on Java 6, performance does slow down as more constants are looked up. However, the slowdown is linear; more constants means more overhead looking them up, and I see no unreasonably degradation. user system total real bar1 A in super: 5.999000 0.000000 5.999000 ( 6.000000) bar2 A in super: 5.808000 0.000000 5.808000 ( 5.808000) bar1 C: 7.633000 0.000000 7.633000 ( 7.633000) bar2 C: 7.580000 0.000000 7.580000 ( 7.580000) bar1 I: 11.972000 0.000000 11.972000 ( 11.972000) bar2 I: 11.879000 0.000000 11.879000 ( 11.879000) JRuby 1.7 on Java 7 (using invokedynamic) appears to perform much better and degrade more slowly, likely because constant lookup is nearly free with invokedynamic. user system total real bar1 A in super: 5.473000 0.000000 5.473000 ( 5.473000) bar2 A in super: 5.363000 0.000000 5.363000 ( 5.363000) bar1 C: 6.091000 0.000000 6.091000 ( 6.091000) bar2 C: 5.952000 0.000000 5.952000 ( 5.952000) bar1 I: 6.875000 0.000000 6.875000 ( 6.875000) bar2 I: 7.184000 0.000000 7.184000 ( 7.185000) There is however an unusual perf degradation for JRuby 1.7 on Java 6, which I'll file in a separate bug. user system total real bar1 A in super: 7.951000 0.000000 7.951000 ( 7.951000) bar2 A in super: 8.416000 0.000000 8.416000 ( 8.416000) bar1 C: 11.433000 0.000000 11.433000 ( 11.433000) bar2 C: 12.246000 0.000000 12.246000 ( 12.246000) bar1 I: 22.286000 0.000000 22.286000 ( 22.286000) bar2 I: 23.562000 0.000000 23.562000 ( 23.562000)

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Chuck Remes
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: