internal iteration for &mut I

[sarah-quinones]

this pr implements internal iteration for &mut I when I: Sized. it additionally inlines some wrapper functions that were not previously inline, which seems to speed things up by a fair amount in some cases.

this lead to up to 3x performance gains across the board for iter:: benches, with only a minor regression for iter::bench_filter_sum

[rust-highfive]

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

Please see the contribution instructions for more information.

[scottmcm]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit cb7f7ee with merge 3e685715a7ece536b2ab653e3433c06c00454bdf...

[the8472]

This was tried several times before, the last one being #82185
Perhaps the changes on function.rs make a difference this time.

[the8472]

The more specific impl shouldn't have default

[bors]

☀️ Try build successful - checks-actions
Build commit: 3e685715a7ece536b2ab653e3433c06c00454bdf (3e685715a7ece536b2ab653e3433c06c00454bdf)

[rust-timer]

Queued 3e685715a7ece536b2ab653e3433c06c00454bdf with parent d77da9d, future comparison URL.

[rust-timer]

Finished benchmarking commit (3e685715a7ece536b2ab653e3433c06c00454bdf): comparison url.

Instruction count

• Primary benchmarks: mixed results
• Secondary benchmarks: mixed results

	mean1	max	count2
Regressions 😿 (primary)	0.8%	25.3%	66
Regressions 😿 (secondary)	0.6%	1.9%	32
Improvements 🎉 (primary)	-0.5%	-1.5%	14
Improvements 🎉 (secondary)	-0.6%	-1.4%	22
All 😿🎉 (primary)	0.6%	25.3%	80

Max RSS (memory usage)

Results

• Primary benchmarks: 🎉 relevant improvement found
• Secondary benchmarks: mixed results

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	4.0%	4.0%	1
Improvements 🎉 (primary)	-2.3%	-2.3%	1
Improvements 🎉 (secondary)	-2.5%	-2.5%	1
All 😿🎉 (primary)	-2.3%	-2.3%	1

Cycles

Results

• Primary benchmarks: 😿 relevant regressions found
• Secondary benchmarks: 😿 relevant regressions found

	mean1	max	count2
Regressions 😿 (primary)	14.7%	37.5%	3
Regressions 😿 (secondary)	2.8%	3.0%	2
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	14.7%	37.5%	3

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking 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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

Footnotes

1. the arithmetic mean of the percent change↩↩²↩³

2. number of relevant changes↩↩²↩³

[scottmcm]

Wow, this totally changes the pattern of LTO in clap:

[sarah-quinones]

well, these don't look like the most promising results ^^'

[compiler-errors]

Presumably this makes compilation slower, but the perf tests don't show the effect on the performance of the compiled code, right?

[sarah-quinones]

are there tests that do?

[the8472]

Other than the std benches (which aren't great) we don't have anything automated to assess runtime performance. In the rustc-perf suite check and doc builds are the closest since they don't codegen but they're probably not diverse enough.

You could try paring down the PR by splitting out some of the changes. E.g. some of the inlining in function.rs doesn't look relevant to iterators. You can also run rustc-perf locally and focus on that one benchmark, that should yield results more quickly (assuming you have a machine that can compile a stage1 rustc in a reasonable amount of time).

[sarah-quinones]

rustc-perf seems to take forever on my machine and i can't display the results after it's finished. so that doesn't seem like a good option for me :/

[the8472]

It can be set to run a subset of the benchmarks, e.g. the serde ones. https://github.com/rust-lang/rustc-perf/tree/master/collector#benchmarking-options
Running the site locally should work as long as it uses the same DB as generated by the collector.

[sarah-quinones]

thanks for the tips! i managed to get it working thanks to your help. it seems that the biggest culprit was inlining the ops::function wrappers.
but even without it i still get a 1-2% regression on deeply-nested-multi

[scottmcm]

I'm going to send this over to

r? @m-ou-se

because I think this is going to be as much a policy decision (about compile-vs-runtime) as it is about the code itself.

[the8472]

Some changes were reverted, let's get new perf results.

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit f6a3462 with merge c20ee6d211784a78b94e26d37cce4e66acea976a...

[bors]

☀️ Try build successful - checks-actions
Build commit: c20ee6d211784a78b94e26d37cce4e66acea976a (c20ee6d211784a78b94e26d37cce4e66acea976a)

[rust-timer]

Queued c20ee6d211784a78b94e26d37cce4e66acea976a with parent aeb5067, future comparison URL.

[rust-timer]

Finished benchmarking commit (c20ee6d211784a78b94e26d37cce4e66acea976a): comparison url.

Instruction count

• Primary benchmarks: mixed results
• Secondary benchmarks: ❌ relevant regressions found

	mean1	max	count2
Regressions ❌ (primary)	0.2%	0.3%	14
Regressions ❌ (secondary)	0.7%	2.0%	16
Improvements ✅ (primary)	-0.4%	-0.7%	7
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	-0.7%	21

Max RSS (memory usage)

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: mixed results

	mean1	max	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.4%	4.5%	8
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.4%	-4.2%	3
All ❌✅ (primary)	-	-	0

Cycles

Results

• Primary benchmarks: ✅ relevant improvement found
• Secondary benchmarks: ✅ relevant improvement found

	mean1	max	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.3%	-2.3%	1
Improvements ✅ (secondary)	-4.1%	-4.1%	1
All ❌✅ (primary)	-2.3%	-2.3%	1

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking 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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

Footnotes

1. the arithmetic mean of the percent change↩↩²↩³

2. number of relevant changes↩↩²↩³

[m-ou-se]

r? @the8472

[the8472]

The compile-time perf numbers are slightly negative, but less so than the previous attempt to do this.

But we need some runtime benchmark numbers to verify that it brings the expected benefits. There are some core::iter benchmarks that I'd expect to show some speedup.

@rustbot author

[Dylan-DPC]

@sarah-ek any updates on this?

[Dylan-DPC]

Closing this as inactive. Feel free to reöpen this pr or create a new pr if you get the time to work on this. Thanks