compiler generate slower code in my benchmarks, after upgrade from 0.13.0 to master

[kostya]

https://github.com/kostya/benchmarks

update is here: kostya/benchmarks@042ee51...78ef5f2

• brainfuck example 1.7 times slower
• matmul example 1.8 times slower
• json example used 2 times more memory

[dotdash]

At least for matmul, this looks like it might be caused by the new Range iterator. I didn't look at the others yet.

Old asm for the inner loop:

  0,05 │4e0:   cmp    %rdx,%rax
       │     ↓ jae    50e
  0,03 │4e5:   mov    (%rbx),%rbp
  0,20 │       cmp    %rbp,%rax
  0,05 │     ↓ jae    527
 28,57 │4ed:   mov    (%r8),%rbp
  0,03 │       mov    (%rdi),%r9
  0,04 │       movsd  (%r9,%rax,8),%xmm1
  0,30 │       mulsd  0x0(%rbp,%rax,8),%xmm1
 40,50 │       lea    0x1(%rax),%rax
  0,06 │       addsd  %xmm1,%xmm0
 29,15 │       cmp    %r12,%rax
       │     ↑ jb     4e0

New asm:

       │1 600:   mov    %rsi,%rcx
 21,23 │         add    $0x1,%rcx
  0,03 │         cmovb  %r12,%rcx
  0,02 │         cmp    %rsi,%rdx
  0,03 │       ↓ jbe    638
 20,87 │1 610:   mov    0x0(%rbp),%rbx
  0,10 │         cmp    %rsi,%rbx
       │       ↓ jbe    646
  0,03 │1 619:   mov    (%r9),%rbx
  0,01 │         mov    (%rdi),%r15
 21,45 │         movsd  (%r15,%rsi,8),%xmm1
  0,21 │         mulsd  (%rbx,%rsi,8),%xmm1
  7,03 │         addsd  %xmm1,%xmm0
 28,06 │         cmp    %r12,%rcx
  0,02 │         mov    %rcx,%rsi
       │       ↑ jb     600

That extra cmov in there is probably the result of the checked add +
mem::swap that the new implementation uses.

cc @aturon

[pnkfelix]

@dotdash when you say "the checked add +", do you mean artihmetic overflow detection? Are you thinking that even when one passes -O without enabling debug-assertions that we are still taking a hit here (though hopefully a much smaller one)?

[aturon]

@pnkfelix I suspect https://github.com/rust-lang/rust/blob/master/src/libcore/iter.rs#L2468-L2470 is the culprit -- the step implementation is using checked_add regardless of debug assertions.

[dotdash]

@pnkfelix Yes, step() explicitly calls checked_add() so it can handle the overflow. The new Range thing combines the old Range and RangeStep. The old Range didn't have to check for overflow because the step size was fixed at 1.

[aturon]

Note that the traits here are unstable, and it may be best to break them up for these distinct cases (or perhaps to instead switch to some other design).

Do either of you want to take this on? If not, I can look into it next week.

[dotdash]

I'm trying to get some other things done and only checked this to see if it's related, so I'll have to pass.

[dotdash]

The brainfuck benchmark seems to be (at least in part) slowed down by integer overflow checks in the SipHasher. I guess nightlies are built with debug-assertions enabled.

[alexcrichton]

Thanks @dotdash for tracking down the iteration problem! #24095 I believe is also about that as well.