-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
optimize slice::Iter::fold #106343
optimize slice::Iter::fold #106343
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit 6a6a41907748388572966d5f214133a8b4efefd5 with merge 3fad16f536f1c5c74f8d8c80d98c3ea988f1e33b... |
💔 Test failed - checks-actions |
6a6a419
to
e42a42b
Compare
@bors try |
⌛ Trying commit e42a42b95ba5c8c3a30fc24badcae06bb0c53a3f with merge d8fe6702c1e876077d9db9bdfe7b8756d8d7de6e... |
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
e42a42b
to
d5801f7
Compare
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
i don't think i'm a good reviewer for libs PRs 😅 the old code was simpler iirc r? @scottmcm |
loop { | ||
// SAFETY: the loop iterates `i in 0..len`, which always is in bounds of | ||
// the slice allocation | ||
acc = f(acc, unsafe { & $( $mut_ )? *self.ptr.add(i).as_ptr() }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How much of the duplication here is essential?
Avoiding the Option
loop seems entirely reasonable to me, but how does this approach compare to something much shorter? For example, something like
for _ in 0..len!(self) {
acc = f(acc, next_unchecked!(self));
}
Or the same with a while (n --> 0)
loop or something, if the Range
is not ok.
And if that's not sufficient, it would be nice to have some comments here about why it's written this way.
(Also, if overloading fold
is worth it, I expect rfold
should be overridden too.)
@rustbot author
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you look at the PR history you'll see that I tried several approaches. A for-in-range loop was one of them. I even used IndexRange
instead of Range
.
And if that's not sufficient, it would be nice to have some comments here about why it's written this way.
Ok, will do.
(Also, if overloading fold is worth it, I expect rfold should be overridden too.)
Maybe, but that'd be optimizing two things at once which makes assessing perf more complicated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a comment.
@rustbot ready
this seems to produce less IR
{ | ||
// this implementation consists of the following optimizations compared to the | ||
// default implementation: | ||
// - do-while loop, as is llvm's preferred loop shape, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's very weird to me that doing this manually is needed, since LLVM has a loop rotation pass to do this. But I guess it's fine.
@bors r+ rollup=never |
// CHECK-NOT: panic | ||
|
||
// Call to panic_cannot_unwind in case of double-panic is expected, | ||
// on LLVM 16 and older, but other panics are not. | ||
// old: filter | ||
// old-NEXT: ; call core::panicking::panic_cannot_unwind | ||
// old-NEXT: panic_cannot_unwind | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now there panic? Or why this was killed.
Ohh, i see it lower, my bad.
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
Finished benchmarking commit (4996b56): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 646.601s -> 647.802s (0.19%) |
…<try> Update `slice::Iter::rfold` to match `slice::Iter::fold` Adds a new codegen test for `rfold`, like the one from rust-lang#106343, and makes a similar fix, updating `rfold` to work via indices too.
Fixes 2 of 4 cases from #106288