Implement TrustedRandomAccess for slice::{Chunks, ChunksMut, Windows}

[sdroege]

As suggested by @bluss in #47115 (comment)

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @kennytm (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[kennytm]

Thanks!

@bors r+

[bors]

📌 Commit 43291c6 has been approved by kennytm

[sdroege]

Thanks for the fast review!

This is going to fail because of #47113
I'll update it in a bit

[kennytm]

Okay. @bors r-

[sdroege]

For good measure, I'll also add unit tests for zipping the 3 iterators. It seems like this is not covered by any of the existing unit tests yet

[sdroege]

This will now fail until #47113 is merged for real

[bors]

☔ The latest upstream changes (presumably #47151) made this pull request unmergeable. Please resolve the merge conflicts.

[sdroege]

Rebased on top of latest master

[bluss]

There is a potential wraparound here isn't there? i is in bounds but start + size can still wrap around. In particular for [(); !0].chunks((!0)/2 +1) I think.

[bluss]

It turns out Rust ICES on that array. For those that don't like my mobile-friendly syntax, !0 is the same as usize::max_value().

However Rust accepts a vec of this length, and we can demo (playground link)

fnmain(){let v = vec![(); !0];let iter = v.chunks((!0)/2 +1);for elt in iter {println!("Found chunk of len {}", elt.len());}}

Which has output:

Found chunk of len 9223372036854775808
Found chunk of len 9223372036854775807

[sdroege]

Good point, thanks. This should probably use checked_add and if it overflows then just use the length.

Will fix in a few hours, thanks for spotting this

[sdroege]

I fixed that now , but also see the discussion at #47126 (comment) and the following 3 comments. It might make sense to reconsider the whole TrustedRandomAccess iterator or at least the zip implementation based on it.

Actually this all seems to have been investigated back then already, so it should all be fine. See top of #47126 (comment)

[sdroege]

I think we're good to go actually

[sdroege]

Some benchmark results, based on the code from #47115 (comment) . Just running a 1920*1080*4 byte array through the normal chunks version.

Something like 1.5% difference (the new version is faster), but consistently. So even for things that llvm can't auto-vectorize it seems to be slightly faster.

Before

$ cargo +local bench
running 1 test
Finished release [optimized] target(s) in 0.0 secs
Running target/release/deps/testing-611256b07a3291e9
test tests::test_bgrx_to_grey ... bench: 5,858,100 ns/iter (+/- 160,940)
test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 0 filtered out
$ cargo +local bench
Finished release [optimized] target(s) in 0.0 secs
Running target/release/deps/testing-611256b07a3291e9
running 1 test
test tests::test_bgrx_to_grey ... bench: 5,842,103 ns/iter (+/- 143,723)
test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 0 filtered out
$ cargo +local bench
Finished release [optimized] target(s) in 0.0 secs
Running target/release/deps/testing-611256b07a3291e9
running 1 test
test tests::test_bgrx_to_grey ... bench: 5,858,885 ns/iter (+/- 193,095)
test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 0 filtered out
$ cargo +local bench
Finished release [optimized] target(s) in 0.0 secs
Running target/release/deps/testing-611256b07a3291e9
running 1 test
test tests::test_bgrx_to_grey ... bench: 5,853,836 ns/iter (+/- 184,774)
test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 0 filtered out

After

$ cargo +local bench
Finished release [optimized] target(s) in 0.0 secs
Running target/release/deps/testing-611256b07a3291e9
running 1 test
test tests::test_bgrx_to_grey ... bench: 5,764,354 ns/iter (+/- 237,465)
test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 0 filtered out
$ cargo +local bench
Finished release [optimized] target(s) in 0.0 secs
Running target/release/deps/testing-611256b07a3291e9
running 1 test
test tests::test_bgrx_to_grey ... bench: 5,764,800 ns/iter (+/- 298,007)
test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 0 filtered out
$ cargo +local bench
Finished release [optimized] target(s) in 0.0 secs
Running target/release/deps/testing-611256b07a3291e9
running 1 test
test tests::test_bgrx_to_grey ... bench: 5,780,834 ns/iter (+/- 234,143)
test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 0 filtered out
$ cargo +local bench
Finished release [optimized] target(s) in 0.0 secs
Running target/release/deps/testing-611256b07a3291e9
running 1 test
test tests::test_bgrx_to_grey ... bench: 5,783,144 ns/iter (+/- 242,745)
test result: ok. 0 passed; 0 failed; 0 ignored; 1 measured; 0 filtered out

[kennytm]

Thanks again! Just wanna confirm, will the expression i * self.chunk_size overflow?

[sdroege]

Thanks again! Just wanna confirm, will the expression i * self.chunk_size overflow?

Yes, but only if you call it with an i that is not in range for the slice. AFAIU this is fine, that's what the "unchecked" / unsafe part of the trait is about: you need to ensure beforehand that the item you want to access does actually exist.

[kennytm]

@bors r+

[bors]

📌 Commit b69c124 has been approved by kennytm

[sdroege]

Thanks a lot @kennytm and @bluss :)

[bors]

⌛ Testing commit b69c124 with merge b98fd52...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: kennytm
Pushing b98fd52 to master...