Reverse Timsort scan direction by Voultapher · Pull Request #107191 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation29 Commits4 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Another PR in the series of stable sort improvements. Best reviewed by looking at the individual commits.
The main perf gain here is for fully ascending (sorted) or reversed inputs for cheap to compare types such as u64, these see a ~1.5x speedup.
Types such as string with indirect pre-fetching see only minor changes. Further speedups are planned in future PRs so, I wouldn't spend too much time for benchmarks here.
This is more clear about the intent of the pointer and avoids problems if the allocation returns a null pointer.
Avoid duplicate insertion sort implementations. Optimize implementations.
Memory pre-fetching prefers forward scanning vs backwards scanning, and the code-gen is usually better. For the most sensitive types such as integers, these are planned to be merged bidirectionally at once. So there is no benefit in scanning backwards.
The largest perf gains are seen for full ascending and descending inputs, which see 1.5x speedups. Random inputs benefit too, and some patterns can loose out, but these losses are minimal.
r? @m-ou-se
(rustbot has picked a reviewer for you, use r? to override)
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library team, which will review and decide on the PR/issue.
labels
Hey! It looks like you've submitted a new PR for the library teams!
If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.
Examples of T-libs-api changes:
- Stabilizing library features
- Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
- Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
- Changing public documentation in ways that create new stability guarantees
- Changing observable runtime behavior of library APIs
Reverse timsort scan direction Reverse Timsort scan direction
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit f297afa with merge ff841929044c3390745330612525de1a62492383...
☀️ Try build successful - checks-actions
Build commit: ff841929044c3390745330612525de1a62492383 (ff841929044c3390745330612525de1a62492383)
This comment has been minimized.
Finished benchmarking commit (ff841929044c3390745330612525de1a62492383): comparison URL.
Overall result: ❌✅ regressions and improvements - ACTION NEEDED
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-perf +perf-regression
Instruction count
This is a highly reliable metric that was used to determine the overall result at the top of this comment.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | 0.4% | [0.2%, 0.6%] | 4 |
| Regressions ❌ (secondary) | - | - | 0 |
| Improvements ✅ (primary) | - | - | 0 |
| Improvements ✅ (secondary) | -0.4% | [-0.4%, -0.4%] | 1 |
| All ❌✅ (primary) | 0.4% | [0.2%, 0.6%] | 4 |
Max RSS (memory usage)
Results
This 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.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | 0.3% | [0.3%, 0.3%] | 1 |
| Regressions ❌ (secondary) | 7.5% | [7.5%, 7.5%] | 1 |
| Improvements ✅ (primary) | -3.1% | [-3.1%, -3.1%] | 1 |
| Improvements ✅ (secondary) | -1.1% | [-1.5%, -0.6%] | 2 |
| All ❌✅ (primary) | -1.4% | [-3.1%, 0.3%] | 2 |
Cycles
Results
This 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.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | 1.0% | [1.0%, 1.0%] | 1 |
| Regressions ❌ (secondary) | - | - | 0 |
| Improvements ✅ (primary) | - | - | 0 |
| Improvements ✅ (secondary) | - | - | 0 |
| All ❌✅ (primary) | 1.0% | [1.0%, 1.0%] | 1 |
@thomcc looking at the regressions and improvements specific to this PR, I get the impression there is no clear win or loss here. Also it seems the magnitude of change is rather small. But I'm not familiar with these benchmarks and their significance, I'd like to hear your impression. It should also be said that these changes are mostly of setup nature, and the next PR plans to introduce the first chunk of larger speedups.
@Voultapher Not sure. It could be noise, but it looks like the regressions are more significant than the improvements. Note that there are 4 primary benchmarks regressed vs 1 secondary (e.g. synthetic) benchmark which improved. I'll try more runs in case it's noise, but it's worth investigating.
@bors try @rust-timer queue runs=5
This comment has been minimized.
⌛ Trying commit 5eff264 with merge 82bc25cb7e57ff1e01bdc1a76269d8c5ff08d2f3...
This comment has been minimized.
Finished benchmarking commit (82bc25cb7e57ff1e01bdc1a76269d8c5ff08d2f3): comparison URL.
Overall result: ❌✅ regressions and improvements - ACTION NEEDED
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-perf +perf-regression
Instruction count
This is a highly reliable metric that was used to determine the overall result at the top of this comment.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | 0.5% | [0.4%, 0.5%] | 2 |
| Regressions ❌ (secondary) | - | - | 0 |
| Improvements ✅ (primary) | -0.5% | [-0.5%, -0.5%] | 1 |
| Improvements ✅ (secondary) | - | - | 0 |
| All ❌✅ (primary) | 0.1% | [-0.5%, 0.5%] | 3 |
Max RSS (memory usage)
Results
This 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.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | 1.9% | [0.3%, 3.5%] | 3 |
| Regressions ❌ (secondary) | 2.8% | [0.9%, 4.7%] | 2 |
| Improvements ✅ (primary) | - | - | 0 |
| Improvements ✅ (secondary) | -2.7% | [-3.5%, -2.1%] | 8 |
| All ❌✅ (primary) | 1.9% | [0.3%, 3.5%] | 3 |
Cycles
Results
This 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.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | - | - | 0 |
| Regressions ❌ (secondary) | 3.3% | [3.1%, 3.6%] | 3 |
| Improvements ✅ (primary) | - | - | 0 |
| Improvements ✅ (secondary) | -2.0% | [-2.0%, -2.0%] | 1 |
| All ❌✅ (primary) | - | - | 0 |
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
@thomcc looking at the two runs, the second one has one primary improvement of 0.5% and one primary regression of 0.5% in the same crate, as well as one further regression of 0.3% in the same crate. The bootstrap timings look all over the place. proc_macro regressed by 2.3% in the second run, but improved by 1.4% in the first run. rustc_builtin_macros regressed by 0.7% or 3.3%. It notes the noise is 1-3%, and pretty much everything falls within this range. I'd argue this change has no significant detrimental effect.
Status: Awaiting review from the assignee but also interested parties.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Hm, fair enough (to be clear: my pickiness here is just to ensure we don't land optimizations that are actually pessimizations, I think the change is good in general).
(I'll do my review this weekend)
One open question is, how much sort performance even influences compiler performance. As IIUC this benchmark suite is focused on compiler performance only.
It is. The compiler definitely performs sorts though, and it wouldn't surprise me if some were in sensitive positions.
Okay, it took a jillion years but I am convinced of this code's correctness. Thanks.
@bors r+
📌 Commit 5eff264 has been approved by thomcc
It is now in the queue for this repository.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
This was referenced
Feb 13, 2023
Finished benchmarking commit (96834f0): comparison URL.
Overall result: ❌✅ regressions and improvements - ACTION NEEDED
Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.
@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance
Instruction count
This is a highly reliable metric that was used to determine the overall result at the top of this comment.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | 0.6% | [0.6%, 0.6%] | 1 |
| Regressions ❌ (secondary) | 0.2% | [0.2%, 0.2%] | 2 |
| Improvements ✅ (primary) | -0.4% | [-0.4%, -0.4%] | 2 |
| Improvements ✅ (secondary) | - | - | 0 |
| All ❌✅ (primary) | -0.1% | [-0.4%, 0.6%] | 3 |
Max RSS (memory usage)
Results
This 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.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | 1.4% | [0.1%, 2.8%] | 2 |
| Regressions ❌ (secondary) | - | - | 0 |
| Improvements ✅ (primary) | -2.7% | [-2.7%, -2.7%] | 1 |
| Improvements ✅ (secondary) | -1.7% | [-2.1%, -1.2%] | 3 |
| All ❌✅ (primary) | 0.1% | [-2.7%, 2.8%] | 3 |
Cycles
Results
This 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.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) | - | - | 0 |
| Regressions ❌ (secondary) | - | - | 0 |
| Improvements ✅ (primary) | - | - | 0 |
| Improvements ✅ (secondary) | -3.0% | [-3.0%, -2.9%] | 2 |
| All ❌✅ (primary) | - | - | 0 |
Regressions are small enough that I think we don't need to investigate this closely.
@rustbot label: perf-regression-triaged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
… r=Mark-Simulacrum
Fix no_global_oom_handling build
provide_sorted_batch in core is incorrectly marked with #[cfg(not(no_global_oom_handling))] which prevents core from building with the cfg enabled.
Nothing in core allocates memory (including this function). The cfg gate is incorrect.
cc @dpaoliello
r? @wesleywiser
The cfg was added by rust-lang#107191
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
… r=Mark-Simulacrum
Fix no_global_oom_handling build
provide_sorted_batch in core is incorrectly marked with #[cfg(not(no_global_oom_handling))] which prevents core from building with the cfg enabled.
Nothing in core allocates memory (including this function). The cfg gate is incorrect.
cc @dpaoliello
r? @wesleywiser
The cfg was added by rust-lang#107191