Improve PartialEq for slices

[dotdash]

Exploiting the fact that getting the length of the slices is known, we
can use a counted loop instead of iterators, which means that we only
need a single counter, instead of having to increment and check one
pointer for each iterator.

Benchmarks comparing vectors with 100,000 elements:

Before:

running 8 tests
test eq1_u8  ... bench:      66,757 ns/iter (+/- 113)
test eq2_u16 ... bench:     111,267 ns/iter (+/- 149)
test eq3_u32 ... bench:     126,282 ns/iter (+/- 111)
test eq4_u64 ... bench:     126,418 ns/iter (+/- 155)
test ne1_u8  ... bench:      88,990 ns/iter (+/- 161)
test ne2_u16 ... bench:      89,126 ns/iter (+/- 265)
test ne3_u32 ... bench:      96,901 ns/iter (+/- 92)
test ne4_u64 ... bench:      96,750 ns/iter (+/- 137)

After:

running 8 tests
test eq1_u8  ... bench:      46,413 ns/iter (+/- 521)
test eq2_u16 ... bench:      46,500 ns/iter (+/- 74)
test eq3_u32 ... bench:      50,059 ns/iter (+/- 92)
test eq4_u64 ... bench:      54,001 ns/iter (+/- 92)
test ne1_u8  ... bench:      47,595 ns/iter (+/- 53)
test ne2_u16 ... bench:      47,521 ns/iter (+/- 59)
test ne3_u32 ... bench:      44,889 ns/iter (+/- 74)
test ne4_u64 ... bench:      47,775 ns/iter (+/- 68)

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

@bors: r+ 9f4d5b4

Nice wins!

[bors]

⌛ Testing commit 9f4d5b4 with merge 66b9277...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt

[lilianmoraru]

That's interesting. Now I am just a little bit confused.
I thought that using iterators is faster in Rust than using for loops because of bounds checking.
Long time ago I saw a benchmark style test that was initially using a for loop and had pretty bad performance compared to C and C++, then somebody else switched it to iterators and the performance was comparable...

[dotdash]

@lilianmoraru In this case, the bounds checks get eliminated by the optimizer, because it can easily prove that it would never trigger, so there's no advantage for iterators here.

But using the zipped iterators, you get two pointers that both need to be incremented and checked, while the counted loop needs to increment and check just a single integer. Different problem ;-)

[jstnlef]

I know this has already been merged and looks fantastic but I, as a Rust n00b, had a question as to why this isn't just

fn ne(&self, other: &[B]) -> bool {
    !self.eq(other);
}

Is it a performance issue to avoid the duplication?

[jstnlef]

Or even just drop this and use the default implementation of ne() from the trait definition.

[hatahet]

I would be interested to know this as well. Could it be because there is call to ne on line 1480, which may not be the same as !eq?

[ranma42]

The documentation for PartialEq states: "Any manual implementation of ne must respect the rule that eq is a strict inverse of ne; that is, !(a == b) if and only if a != b."
Under this assumption, ne can always re-use the implementation from the trait definition. I would expect the compiler to do a good job optimising it as it can fold the negation either on the possible outcomes or on the ne usage. Unless some benchmarking suggests otherwise, I would assume that avoiding the duplication is preferred.

[hatahet]

I suppose we'll have to wait to hear back from @dotdash then :-)

[dotdash]

I don't remember exactly why I didn't change that, but probably I was just too lazy to come up with enough useful testcases (involving at least various calling- and inlining-scenarios) to make sure that relying on the simple negation implementation doesn't affect performance negatively. Benchmarking welcome!

[jstnlef]

I'll see if I can find some time this weekend to test it out.