Implement iterator specialization traits on more adapters by the8472 · Pull Requ...
source link: https://github.com/rust-lang/rust/pull/85528
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Conversation
Member
This adds
TrustedLentoSkipandStepByTrustedRandomAccesstoSkipInPlaceIterableandSourceItertoCopiedandCloned
The first two might improve performance in the compiler itself since skip is used in several places. Constellations that would exercise the last point are probably rare since it would require an owning iterator that has references as Items somewhere in its iterator pipeline.
Improvements for Skip:
# old
test iter::bench_skip_trusted_random_access ... bench: 8,335 ns/iter (+/- 90)
# new
test iter::bench_skip_trusted_random_access ... bench: 2,753 ns/iter (+/- 27)
Collaborator
|
r? @yaahc (rust-highfive has picked a reviewer for you, use r? to override) |
added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label
Collaborator
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label
Contributor
|
⌛ Trying commit 838b07beaca15f5614619bcee070ef5263a805ed with merge e056521d347c0ec9e2f6a0a140406f4b0a06c011... |
Contributor
|
☀️ Try build successful - checks-actions |
Collaborator
|
Queued e056521d347c0ec9e2f6a0a140406f4b0a06c011 with parent 99e3aef, future comparison URL. |
Collaborator
|
Finished benchmarking try commit (e056521d347c0ec9e2f6a0a140406f4b0a06c011): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label
Member
Author
|
Looks like noise. Or if it isn't then it's tiny impact at least. I guess the I'll write some benchmarks to see if these actually improve some assembly. |
Member
Author
|
I have added a benchmark |
if Self::MAY_HAVE_SIDE_EFFECT && idx == 0 { |
||
for skipped_idx in 0..self.n { |
||
drop(try_get_unchecked(&mut self.iter, skipped_idx)); |
||
} |
Member
Author
In light of #85969 I must note that this alters (undocumented) side-effects for backwards iteration, albeit in less surprising ways.
This block is written to preserve side-effects of the skipped portion of the iterator during forward iteration. During backward iteration it will lead to the whole skipped portion being drained on the last (backwards) step instead of only the first item beyond the skipped portion, i.e. it behaves as if the last item were obtained by a next() instead of next_back().
Hm, so, my interpretation of what you're saying: we're picking idx == 0, which might not actually be the first index the user iterates over (and won't be in backwards iteration).
But I think my interpretation is probably wrong -- I've tried several times and I cannot manage to find a case where your patch causes different behavior in map(|i| dbg!(i)).skip(n) behavior in forward or backward iteration. Do you have an example where it makes causes an observable difference?
Member
Author
next_back doesn't touch the inner's skipped prefix. But anything that goes backwards via __iterator_get_unchecked (e.g. Zip) would once it hits index 0.
@the8472 Okay, this is a slight behavioral change to behavior we never made a promise about. I think it's a change we're allowed to make, but to be safe, that decision should be left to t-libs-api FCP.
Do you mind writing up the details about before/after differences so that that can be done?
added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label
Member
|
Going to pass this one off because I'm not familiar enough with this part of r? @m-ou-se |
added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
labels
added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
labels
Contributor
|
☔ The latest upstream changes (presumably #85874) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
Contributor
|
I understand merge conflicts accumulate over time. Didn't mean to cause annoyance, but between thomcc's last comment and your last comment, it wasn't clear to me whether everything was addressed. Especially given how long this had been open without update, I figured it was worth an ask. |
Contributor
|
I know this has been run through perf a couple times, but I just want to throw the (very new) runtime performance suite at something likely to jostle it to see if it gets anything. Sorry for the noise! @bors try @rust-timer queue |
This comment has been minimized.
added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label
Contributor
|
⌛ Trying commit 3af552a with merge 1f4585dbcb1b7f4971a8c2a76d1b74dff98a774a... |
Contributor
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
Collaborator
|
Finished benchmarking commit (1f4585dbcb1b7f4971a8c2a76d1b74dff98a774a): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeResults Bootstrap: 652.994s -> 652s (-0.15%) |
removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label
Contributor
|
Hell yeah, a needle wiggled! I don't think anyone should derive much information from this, given that we don't know yet if this is a good suite of benchmarks, but it's admittedly more than zero! |
Contributor
|
idk, despite my enthusiasm for the exercising of the runtime perf test suite, with what feels like minimal/unclear benefit, it's hard to argue that the addition of a bunch of hard-to-audit |
Contributor
|
r? libs-api Needs FCP due to inducing user-facing behavior changes in some iterator adapters in order to make the given microbenchmark go zoom. Behavior change is subtle, however, and doesn't seem to be earthshattering, see this comment. |
Member
|
This causes a minor behavior change, see #85528 (comment). However I don't expect this to be an issue in practice since this behavior was never guaranteeed. @rfcbot fcp merge |
|
Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it.
labels
Member
|
This is waiting on 1 more checkbox to enter FCP, among them @the8472's, whose PR this is. I almost but not quite feel at liberty to check your box for you. Want to do the honors? 😉 |
Member
Author
|
Sure, I can do that if that's ok? Approving one's own stuff always seems questionable. But I guess we'd have to tell the bot to remove one of the boxes, which we don't. 🤷 |
added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label
Member
|
@the8472 "N–2 of the team thinks that this is a good idea (and no objections)" is the bar. In my experience it's always been by design that the PR author would be included in that count if they're a member of the relevant team. Actually, most often the PR author is the one who proposes the FCP in the first place in that situation, so then they automatically get counted. |
added finished-final-comment-period The final comment period is finished for this PR / Issue. to-announce Announce this issue on triage meeting
and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised.
labels
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
No milestone
Successfully merging this pull request may close these issues.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK