Add slice::ExactChunks and ::ExactChunksMut iterators #47126

sdroege · 2018-01-02T09:28:52Z

These guarantee that always the requested slice size will be returned
and any leftoever elements at the end will be ignored. It allows llvm to
get rid of bounds checks in the code using the iterator.

This is inspired by the same iterators provided by ndarray.

Fixes #47115

I'll add unit tests for all this if the general idea and behaviour makes sense for everybody.
Also see #47115 (comment) for an example what this improves.

rust-highfive · 2018-01-02T09:28:57Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @bluss (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.

bluss · 2018-01-02T11:34:48Z

src/libcore/slice/mod.rs

+        } else {
+            let start = self.v.len() - self.chunk_size;
+            Some(&self.v[start..])
+        }


We can use next back here to save that code duplication

bluss · 2018-01-02T20:31:58Z

src/libcore/slice/mod.rs

+}
+
+#[unstable(feature = "exact_chunks", issue = "47115")]
+impl<'a, T> ExactSizeIterator for ExactChunksMut<'a, T> {}


We can implement is_empty since it is actually simpler than size_hint/len (saves the division)

bluss · 2018-01-02T20:34:04Z

src/libcore/slice/mod.rs

+        } else {
+            let start = (self.v.len() - self.chunk_size) / self.chunk_size * self.chunk_size;
+            Some(&mut self.v[start..])
+        }


Same, we can use next_back here. (The code here in ExactChunksMut::last is not updated to take advantage of the property that self.v is evenly divisible by the chunk size)

bluss · 2018-01-02T20:34:51Z

src/libcore/slice/mod.rs

+    }
+
+    #[inline]
+    fn nth(&mut self, n: usize) -> Option<Self::Item> {


I think this method can be much simpler if we just use the fact that self.v is evenly divisible by the chunk size. Same for the mutable version.

My first try would be to use n to find the new start of self.v, then call self.next(). Maybe that can be improved upon.

bluss · 2018-01-02T20:42:53Z

I've submitted code review, but I think we need the libs team and the ticky boxes to weigh in on whether to include this in libcore & libstd. I think these methods seem fine; ~~a bit obscure~~ (*). An unfortunate point is that these would be yet better with const generics and producing &[T; N] and &mut [T; N] respectively. (Unfortunate since such ideas mean that we need to wait for it to be available in Rust).

cc @rust-lang/libs

(*) Looking closer at the resulting difference it's not exactly obscure, it's essential functionality for that type of code

sdroege · 2018-01-02T21:59:15Z

@bluss Thanks for your review comments, I've updated everything accordingly. Still no tests yet, they'll come if this is considered a good idea :)

bluss · 2018-01-02T22:03:39Z

src/libcore/slice/mod.rs

+            let (_, snd) = self.v.split_at(start);
+            self.v = snd;
+            assert!(self.v.len() == self.chunk_size);
+            self.next()


Why the assertion? It doesn't look correct as written, maybe >= was intended?

I'd probably avoid the assertion, there will be a bounds check equivalent to it anyhow in next(?).

Indeed, I was confused. Thanks!

sdroege · 2018-01-02T23:06:07Z

@bluss was this what you were thinking of with regards to TrustedRandomAccess in #47115 (comment) ?

sdroege · 2018-01-03T11:14:50Z

The TrustedRandomAccess impl minimally changes the assembly in my testcase (same number of instructions, basically equivalent) but has no real effect on the performance.

bluss · 2018-01-03T20:19:55Z

@sdroege Yep that's what I was thinking and, that's good info that it doesn't change anything. I think it can still be a good optimization in other cases?

sdroege · 2018-01-03T22:46:26Z

I'm not entirely sure about that, also with regards to #47142. I'll do some benchmarking tomorrow.

Basically (for zip) we assume here that the compiler will optimize away the multiplication on each access. Without the TrustedRandomAccess it would only be an increment every time instead of a multiplication, if the compiler does not optimize the multiplication away.

I assume when the trait was added and the specialized implementation for zip, this was all measured and taken into account though.

bluss · 2018-01-03T23:03:03Z

@sdroege I think you bring up details that matter; maybe a smarter zip specialization could be adopted that helps with that, or maybe even adding a more special case.

In my understanding, the current zip specialization helps with something "dumber" than that. In completely general .zip(), we have two input iterators, and for each iteration, we need to ask them both if they have a next element; and this didn't compile well for some common loops with slices at least at the time when the specialization was added. With zip specialization, we only need to check "is there a next element" one time per iteration, and this is true even if we have a n-ary combination of .zip()s.

sdroege · 2018-01-04T09:29:30Z

@bluss If you don't mind I would suggest to skip the commit that adds the TrustedRandomAccess from here so that we can discuss about the API itself instead. And move that commit to another PR at a later time.

In the meantime I'll do some more analysis and benchmarking of the effect of the trait impl for the normal Chunks (and the other three).

@sdroege I think you bring up details that matter; maybe a smarter zip specialization could be adopted that helps with that, or maybe even adding a more special case.

Something that just increments on each iteration would be useful, as that would not rely on the optimizer to get rid of the multiplication. Something like a next_unsafe that you must only call if you know that there is a next item. That also seems like it would solve the original purpose of the trait.

But this all seems like something for another issue to discuss it

bluss · 2018-01-04T09:42:50Z

Yes, let's split off that commit. Fwiw, both the current approach and a next unchecked approach were considered the first time. I think current was marginally better, but why not look at it again and with a wider use case.

sdroege · 2018-01-04T09:49:39Z

Removed that commit. Now this should all be good to be reviewed for the actual new API.

I'm going to do some archaeology about the original implementation and reason for the trait being like this, and then open a new issue about it.

sdroege · 2018-01-04T11:05:25Z

@bluss Ok, you already did all that very same investigation I was going to do back then :) See #33090 (comment) and #33090 (comment)

Basically the counter-index approach instead of pointer-increment can be optimized better by llvm. So I guess let's keep it at that and I'll re-add the commit here again. The chunks iterators are more or less the same as the normal slice iterators in every regard.

So in summary, I think the open questions here are the following:

Does it make sense to add such a specialized chunks variant?
Tracking issue for chunks_exact/_mut; slice chunks with exact size #47115 (comment) and Tracking issue for chunks_exact/_mut; slice chunks with exact size #47115 (comment) would suggest so as it can improve performance a lot. It also potentially improves usability a bit as the code using the iterator can really assume that each slice will be exactly that many elements.
Should it use const generics?
This would mean using &[T; N] instead of &[T] (with a fixed size the compiler can infer). The function signature would be quite more complicated, and how to call it too (exact_chunks(n) vs exact_chunks::<n>()), but it seems more explicit (you have the slice length directly in your types).
It also has the disadvantage that having the function available and having it be stabilized would be coupled with const generics.
But I think the biggest disadvantage, and a reason why having both might be useful, is that the chunk size would have to be always known at compile-time.

leonardo-m · 2018-01-06T20:36:08Z

and a reason why having both might be useful, is that the chunk size would have to be always known at compile-time.

I agree that having both could be better. Despite the increased API.

sdroege · 2018-01-09T16:02:50Z

Rebased against latest master to solve a couple of merge conflicts.

mbrubeck · 2018-01-09T18:12:52Z

Should the documentation mention that these methods may be faster than the existing ones? This seems like important information for helping users choose the appropriate iterator for a given use case.

sdroege · 2018-01-09T20:59:37Z

Should the documentation mention that these methods may be faster than the existing ones? This seems like important information for helping users choose the appropriate iterator for a given use case.

Done, thanks

Kimundi · 2018-01-09T22:06:49Z

I think the name exact_chunks for an API that works with dynamic, but fixed sizes is fine, and consistent with other std API like read_exact.

In the same sense, if we would provide and API that works with const generics and [T; N], then we should call that fixed_chunks to be consistent with the naming of fixed sized arrays. This naturally leads to providing both APIs, in my opinion.

In the libs meeting the possible concern got raised about it not being obvious that elements might get dropped at the end. I wounder if a solution to that would be what we did for copy_from_slice: Just panic if the length of the slice is not evenly divisible into chunks, forcing the user to explicitly handle the case up-front.

alexcrichton · 2018-01-10T02:27:11Z

The libs team discussed this today and was overall on board with landing this (@Kimundi commented above) so @bluss feel free to r+ when you're satisfied!

- Simplify nth() by making use of the fact that the slice is evenly divisible by the chunk size, and calling next() instead of duplicating it - Call next_back() in last(), they are equivalent - Implement ExactSizeIterator::is_empty()

…ter by the compiler And also link from the normal chunks iterator to the exact_chunks one.

…t test This way more useful information is printed if the test ever fails.

…_mut tests Easy enough to do and ensures that the whole chunk is as expected instead of just the element that was looked at before.

These are basically modified copies of the chunks/chunks_mut tests.

sdroege · 2018-01-13T10:19:26Z

Thanks, changed the "Fixes ..." to "See ...", everything else the same.

bluss · 2018-01-13T10:20:31Z

Thanks!

@bors r+

bors · 2018-01-13T10:20:31Z

📌 Commit 5f4fc82 has been approved by bluss

sdroege · 2018-01-13T10:42:40Z

Thanks @sdroege. The tracking issue you set up for this is #47115, I'll edit it a bit and maybe you can put in the remaining questions.

I've added the open question there now (panic or skip left-over elements). I don't think there were any other questions here

Add slice::ExactChunks and ::ExactChunksMut iterators These guarantee that always the requested slice size will be returned and any leftoever elements at the end will be ignored. It allows llvm to get rid of bounds checks in the code using the iterator. This is inspired by the same iterators provided by ndarray. Fixes rust-lang#47115 I'll add unit tests for all this if the general idea and behaviour makes sense for everybody. Also see rust-lang#47115 (comment) for an example what this improves.

Rollup of 10 pull requests - Successful merges: #47120, #47126, #47277, #47330, #47368, #47372, #47414, #47417, #47432, #47443 - Failed merges: #47334

Kerollmops · 2018-01-20T11:29:45Z

src/liballoc/slice.rs

+    ///
+    /// Due to each chunk having exactly `chunk_size` elements, the compiler
+    /// can often optimize the resulting code better than in the case of
+    /// [`chunks`].


Whoops, it seems this is not referenced, resulting in a broken link.

Indeed, thanks for noticing. I'll submit a PR later, not sure yet why... or why rustdoc does not error out on broken links. Oh well :)

Ah understood why!

See sdroege@1756f68 . It seems like you have to provide "full" paths somewhere in your doc chunk for "shortened" links. rustdoc doesn't seem to check the current scope for things with the same name.

I knew well why, you didn't reference the links in the scope :)
I asked more for:

why rustdoc does not error out on broken links

it should.....

Kerollmops · 2018-01-20T11:30:38Z

src/liballoc/slice.rs

+    ///
+    /// Due to each chunk having exactly `chunk_size` elements, the compiler
+    /// can often optimize the resulting code better than in the case of
+    /// [`chunks_mut`].


broken too.

…chunk/exact_chunks_mut docs See rust-lang#47126 (comment)

…nks, r=kennytm Fix broken links to other slice functions in chunks/chunks_mut/exact_… …chunk/exact_chunks_mut docs See rust-lang#47126 (comment)

Kerollmops · 2018-05-30T09:25:33Z

src/libcore/slice/mod.rs

+
+    #[inline]
+    fn next(&mut self) -> Option<&'a [T]> {
+        if self.v.len() < self.chunk_size {


This condition can probably be simplified to just self.v.is_empty() because we already know that the slice has a length that is a modulo of the chunk_size so the only reason why the slice can be too short is that the slice is empty.

Yes, but for that see also #47115 (comment)

Kerollmops · 2018-05-30T09:43:38Z

src/libcore/slice/mod.rs

+    #[inline]
+    fn nth(&mut self, n: usize) -> Option<Self::Item> {
+        let (start, overflow) = n.overflowing_mul(self.chunk_size);
+        if start >= self.v.len() || overflow {


This condition seems wrong, we must test the overflow before the test of the start is greater or not than the self.v.len() because if we have overflowed so the start has been wrapped and can be smaller than the self.v.len(). And the returned value will be wrong.

We probably want to panic if the computation is impossible and will overflow here, no ?
https://doc.rust-lang.org/std/iter/trait.Iterator.html#panics

EDIT: I am wrong about the order of the conditions, this is a || we don't care in this case.

You still think that an overflow should panic instead of doing nothing? This is currently the same behaviour as for the other chunks iterators and what was stabilized for them

Yes, I think checked but silent overflows is not a good behavior. But this is a really rare behavior to have an overflow to address the nth element, so this is not something we should care of.

I agree but I think it's more problematic to have inconsistent behaviour between the different chunk iterators (and we can't change the stabilized existing ones). But if there's disagreement I'd be happy to change it

If you think that consistency between chunk iterators is important, I think we must have consistency between all other iterators and panic if an overflow occurs like the Enumerate adapter do, so it could be a great improvement to update the current implementation of the Chunks/ChunksMut to follow this rule. Don't you think ?

Can you open an issue about that? I would generally agree (and also think that panicking would be cleaner here) but changing Chunks/ChunksMut could be considered a breaking change

Here is the issue #51254

rust-highfive assigned bluss Jan 2, 2018

kennytm added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jan 2, 2018

bluss reviewed Jan 2, 2018

View reviewed changes

bluss approved these changes Jan 2, 2018

View reviewed changes

kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 3, 2018

alexcrichton added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 3, 2018

sdroege mentioned this pull request Jan 4, 2018

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

Merged

sdroege force-pushed the exact-chunks branch from b306440 to 391d837 Compare January 4, 2018 09:45

bluss approved these changes Jan 6, 2018

View reviewed changes

sdroege force-pushed the exact-chunks branch from 9b8d9c1 to 8aa1b90 Compare January 9, 2018 16:02

sdroege added 8 commits January 13, 2018 12:18

Fix doctests for slice::exact_chunks() for real

e51a89a

Apply review comments from @bluss

aa0c08a

- Simplify nth() by making use of the fact that the slice is evenly divisible by the chunk size, and calling next() instead of duplicating it - Call next_back() in last(), they are equivalent - Implement ExactSizeIterator::is_empty()

Remove useless assertion

cea36f4

Implement TrustedRandomAccess for slice::{ExactChunks, ExactChunksMut}

6bf1dfd

Mention in the exact_chunks docs that this can often be optimized bet…

8a82e8e

…ter by the compiler And also link from the normal chunks iterator to the exact_chunks one.

Use assert_eq!() instead of assert!(a == b) in slice chunks_mut() uni…

baa81dc

…t test This way more useful information is printed if the test ever fails.

Test the whole chunks instead of just an element in the chunks/chunks…

ed77483

…_mut tests Easy enough to do and ensures that the whole chunk is as expected instead of just the element that was looked at before.

Add unit tests for exact_chunks/exact_chunks_mut

5f4fc82

These are basically modified copies of the chunks/chunks_mut tests.

sdroege force-pushed the exact-chunks branch from a196f41 to 5f4fc82 Compare January 13, 2018 10:19

GuillaumeGomez mentioned this pull request Jan 14, 2018

Rollup of 8 pull requests #47435

Closed

kennytm mentioned this pull request Jan 15, 2018

Rollup of 10 pull requests #47445

Merged

bors added a commit that referenced this pull request Jan 15, 2018

Auto merge of #47445 - kennytm:rollup, r=kennytm

57850e5

Rollup of 10 pull requests - Successful merges: #47120, #47126, #47277, #47330, #47368, #47372, #47414, #47417, #47432, #47443 - Failed merges: #47334

bors merged commit 5f4fc82 into rust-lang:master Jan 15, 2018

Kerollmops reviewed Jan 20, 2018

View reviewed changes

sdroege added a commit to sdroege/rust that referenced this pull request Jan 21, 2018

Fix broken links to other slice functions in chunks/chunks_mut/exact_…

1756f68

…chunk/exact_chunks_mut docs See rust-lang#47126 (comment)

sdroege mentioned this pull request Jan 21, 2018

Fix broken links to other slice functions in chunks/chunks_mut/exact_… #47632

Merged

Kerollmops reviewed May 30, 2018

View reviewed changes

Kerollmops mentioned this pull request May 31, 2018

chunk like Iterators should panic on overflow #51254

Closed

Add slice::ExactChunks and ::ExactChunksMut iterators #47126

Add slice::ExactChunks and ::ExactChunksMut iterators #47126

Conversation

sdroege commented Jan 2, 2018 • edited Loading

rust-highfive commented Jan 2, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bluss Jan 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bluss commented Jan 2, 2018 • edited Loading

sdroege commented Jan 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sdroege commented Jan 2, 2018

sdroege commented Jan 3, 2018

bluss commented Jan 3, 2018

sdroege commented Jan 3, 2018

bluss commented Jan 3, 2018

sdroege commented Jan 4, 2018

bluss commented Jan 4, 2018

sdroege commented Jan 4, 2018

sdroege commented Jan 4, 2018 • edited Loading

leonardo-m commented Jan 6, 2018

sdroege commented Jan 9, 2018

mbrubeck commented Jan 9, 2018

sdroege commented Jan 9, 2018

Kimundi commented Jan 9, 2018 • edited Loading

alexcrichton commented Jan 10, 2018

sdroege commented Jan 13, 2018

bluss commented Jan 13, 2018

bors commented Jan 13, 2018

sdroege commented Jan 13, 2018

Kerollmops Jan 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kerollmops Jan 21, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kerollmops May 30, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kerollmops May 31, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sdroege commented Jan 2, 2018 •

edited

Loading

bluss Jan 2, 2018 •

edited

Loading

bluss commented Jan 2, 2018 •

edited

Loading

sdroege commented Jan 2, 2018 •

edited

Loading

sdroege commented Jan 4, 2018 •

edited

Loading

Kimundi commented Jan 9, 2018 •

edited

Loading

Kerollmops Jan 20, 2018 •

edited

Loading

Kerollmops Jan 21, 2018 •

edited

Loading

Kerollmops May 30, 2018 •

edited

Loading

Kerollmops May 31, 2018 •

edited

Loading