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 |
There was a problem hiding this comment.
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.
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.
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.
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.
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