impls on arrays seem slower than equivalent tuples

[smmalis37]

When running the following program:

Cargo.toml:

[dependencies]
criterion = "0.3"

main.rs:

use criterion::{black_box, Criterion};

fn main() {
    let mut c = Criterion::default();
    c.bench_function("partialeq-array", |b| {
        b.iter(|| {
            let a = black_box([0; 3]);
            let b = black_box([0; 3]);
            for _ in 0..1_000_000 {
                black_box(a.eq(&b));
            }
        })
    });
    c.bench_function("partialeq-tuple", |b| {
        b.iter(|| {
            let a = black_box((0, 0, 0));
            let b = black_box((0, 0, 0));
            for _ in 0..1_000_000 {
                black_box(a.eq(&b));
            }
        })
    });
}

I get these results in debug builds:

partialeq-array         time:   [46.308 ms 46.462 ms 46.618 ms]
partialeq-tuple         time:   [31.133 ms 31.230 ms 31.339 ms]

And these results in release builds:

partialeq-array         time:   [628.51 us 633.17 us 638.23 us]
partialeq-tuple         time:   [211.77 us 212.61 us 213.60 us]

I had expected these to be equivalent, but tuples are significantly faster than arrays. This seems to apply to any size of number (i8, u32, etc), and some other traits as well (notably Hash).

[smmalis37]

@rustbot label I-slow

[smmalis37]

Tagging another interested party: @aldanor

[sfackler]

The only difference in the compiled code is the array impl's extra check for pointer equality: https://rust.godbolt.org/z/1ea4e5

[sfackler]

Huh, on 1.48.0 the tuple impl ends up branching on each value, and on nightly the array impl spills to the stack (?!).

https://rust.godbolt.org/z/oE41ed

[smmalis37]

Correct me if I'm wrong, but since those arrays are being passed by value their addresses can never be the same right? So that check and branch are completely pointless? I could understand if it was over a slice or a ref to an array, but not on an array itself.

[smmalis37]

Results on current nightly:
Debug:

partialeq-array         time:   [47.103 ms 47.252 ms 47.431 ms]
partialeq-tuple         time:   [32.375 ms 32.441 ms 32.513 ms]

Release:

partialeq-array         time:   [672.38 us 674.07 us 676.14 us]
partialeq-tuple         time:   [207.67 us 207.94 us 208.27 us]

Looks basically the same to me, just a little bit of noise.

[nikic]

IR variant of the above godbolt link is enlightening: https://rust.godbolt.org/z/Wb4dTY

Looks like this is fallout from the switch to pass values smaller than 2 registers by-value. For the array case this ends up requiring a stack copy, because the bcmp is expanded too late to avoid it. For the tuple case the value is passed as an i96 (!!!) and then parts are extracted from it using bit arithmetic. I guess in the latter case LLVM should probably fold these comparisons down to one comparison of i96.

[sfackler]

Correct me if I'm wrong, but since those arrays are being passed by value their addresses can never be the same right?

That is true, but passing that information to LLVM results in miscompilations IIRC so it's not done by default.

[erikdesjardins]

The only difference in the compiled code is the array impl's extra check for pointer equality

I thought we removed this comparison because it caused other problems, but the PR languished and died; resurrected in #80209.