Skip to content

Merge mir query analysis invocations #140856

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

Merged
merged 3 commits into from
May 18, 2025
Merged

Conversation

oli-obk
Copy link
Contributor

@oli-obk oli-obk commented May 9, 2025

r? @ghost

same thing as #140854 just a different set of queries

Doing this in general has some bad cache coherence issues because the query caches are laid out in Vec lists per query where each index refers to a DefId in the same order as we're iterating. Iterating two or more lists at the same time does have cache issues, so I want to poke a bit at it to see if we can't merge just a few of them at a time.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 9, 2025
@oli-obk
Copy link
Contributor Author

oli-obk commented May 9, 2025

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label May 9, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request May 9, 2025
Merge mir query analysis invocations

r? `@ghost`

same thing as rust-lang#140854 just a different set of queries
@bors
Copy link
Collaborator

bors commented May 9, 2025

⌛ Trying commit d63b394 with merge bddede8...

@bors
Copy link
Collaborator

bors commented May 9, 2025

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

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (bddede8): comparison URL.

Overall result: ❌ regressions - no 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.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.6% [0.6%, 0.6%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary -0.9%, secondary -2.2%)

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.7% [0.4%, 1.1%] 3
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-1.1% [-2.7%, -0.5%] 20
Improvements ✅
(secondary)
-2.2% [-4.0%, -0.4%] 2
All ❌✅ (primary) -0.9% [-2.7%, 1.1%] 23

Cycles

Results (primary 1.5%, secondary 0.2%)

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.8% [0.4%, 3.9%] 26
Regressions ❌
(secondary)
4.5% [3.2%, 5.4%] 10
Improvements ✅
(primary)
-0.8% [-1.3%, -0.5%] 3
Improvements ✅
(secondary)
-7.0% [-7.8%, -6.3%] 6
All ❌✅ (primary) 1.5% [-1.3%, 3.9%] 29

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 773.559s -> 774.531s (0.13%)
Artifact size: 365.71 MiB -> 365.58 MiB (-0.03%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label May 9, 2025
@oli-obk
Copy link
Contributor Author

oli-obk commented May 9, 2025

@Zoxc do you think changes like this are detrimental to parallel rustc?

@Zoxc
Copy link
Contributor

Zoxc commented May 9, 2025

Merging parallel sections is generally good, but actual measurements are also nice.

@oli-obk oli-obk marked this pull request as ready for review May 10, 2025 07:39
@oli-obk
Copy link
Contributor Author

oli-obk commented May 10, 2025

Right. I'll figure out how to do that locally. But until then

r? @nnethercote

@oli-obk
Copy link
Contributor Author

oli-obk commented May 10, 2025

Ah no I forgot the regression only shows in cycles, not in instructions...

@oli-obk
Copy link
Contributor Author

oli-obk commented May 10, 2025

Branch misses and cache misses are also really badly regressed. So my original analysis still stands, even if wall time itself is not really affected

@@ -233,6 +222,17 @@ pub fn check_crate(tcx: TyCtxt<'_>) {
}
});

if tcx.features().rustc_attrs() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why dump attrs stuff later? I'm not opposed, just there's no motivation given.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to make space there to merge the parallel blocks before and after

@nnethercote
Copy link
Contributor

Branch misses and cache misses are also really badly regressed. So my original analysis still stands, even if wall time itself is not really affected

Can you remind me what the original analysis is? I've lost track of the motivation for this PR. Is it for code simplification, performance, both/something else? Thanks.

@oli-obk
Copy link
Contributor Author

oli-obk commented May 14, 2025

Doing this in general has some bad cache coherence issues because the query caches are laid out in Vec lists per query where each index refers to a DefId in the same order as we're iterating. Iterating two or more lists at the same time does have cache issues, so I want to poke a bit at it to see if we can't merge just a few of them at a time.

@oli-obk
Copy link
Contributor Author

oli-obk commented May 14, 2025

The reasons I'm doing it is that

  • merging those blocks allows for more parallelism as you don't run parallel blocks in sequence
  • merging blocks allows merging analysis queries shrinking the dep graph
  • should allow us to do more early aborting in case of errors and/or moving query calls from the analysis query into others that allow early aborting the others (and doing more tainting and stuff)

@nnethercote
Copy link
Contributor

The reasons I'm doing it is that

Aha, that helps a lot. Please put that explanation in the commit message for the third commit, and then r=me, thanks.

The reasons I'm doing it is that

* merging those blocks allows for more parallelism as you don't run parallel blocks in sequence
* merging blocks allows merging analysis queries shrinking the dep graph
* should allow us to do more early aborting in case of errors and/or moving query calls from the analysis query into others that allow early aborting the others (and doing more tainting and stuff)
@oli-obk
Copy link
Contributor Author

oli-obk commented May 14, 2025

@bors r=nnethercote

@bors
Copy link
Collaborator

bors commented May 14, 2025

📌 Commit e011c43 has been approved by nnethercote

It is now in the queue for this repository.

@bors bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 14, 2025
@bors bors added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 14, 2025
@oli-obk
Copy link
Contributor Author

oli-obk commented May 14, 2025

@bors retry

@bors bors added S-waiting-on-bors 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 May 14, 2025
@oli-obk
Copy link
Contributor Author

oli-obk commented May 14, 2025

@bors rollup=never

bors added a commit to rust-lang-ci/rust that referenced this pull request May 14, 2025
Merge mir query analysis invocations

r? `@ghost`

same thing as rust-lang#140854 just a different set of queries

Doing this in general has some bad cache coherence issues because the query caches are laid out in Vec<QueryResult> lists per query where each index refers to a DefId in the same order as we're iterating. Iterating two or more lists at the same time does have cache issues, so I want to poke a bit at it to see if we can't merge just a few of them at a time.
@bors
Copy link
Collaborator

bors commented May 14, 2025

⌛ Testing commit e011c43 with merge d8ccc90...

@bors
Copy link
Collaborator

bors commented May 14, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 14, 2025
@clubby789
Copy link
Contributor

System.IO.IOException: There is not enough space on the disk - @bors retry

@bors bors added S-waiting-on-bors 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 May 14, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request May 14, 2025
Merge mir query analysis invocations

r? `@ghost`

same thing as rust-lang#140854 just a different set of queries

Doing this in general has some bad cache coherence issues because the query caches are laid out in Vec<QueryResult> lists per query where each index refers to a DefId in the same order as we're iterating. Iterating two or more lists at the same time does have cache issues, so I want to poke a bit at it to see if we can't merge just a few of them at a time.
@bors
Copy link
Collaborator

bors commented May 14, 2025

⌛ Testing commit e011c43 with merge ae6350f...

@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@bors
Copy link
Collaborator

bors commented May 14, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 14, 2025
@oli-obk
Copy link
Contributor Author

oli-obk commented May 17, 2025

@bors retry

@bors bors added S-waiting-on-bors 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 May 17, 2025
@bors
Copy link
Collaborator

bors commented May 17, 2025

⌛ Testing commit e011c43 with merge 16244bc...

@bors
Copy link
Collaborator

bors commented May 18, 2025

☀️ Test successful - checks-actions
Approved by: nnethercote
Pushing 16244bc to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 18, 2025
@bors bors merged commit 16244bc into rust-lang:master May 18, 2025
7 checks passed
@rustbot rustbot added this to the 1.89.0 milestone May 18, 2025
Copy link

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 777d372 (parent) -> 16244bc (this PR)

Test differences

Show 4 test diffs

4 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 16244bc37a6ff610daa38afcddfc1a8bb226702e --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. x86_64-apple-1: 7371.2s -> 9885.6s (34.1%)
  2. dist-apple-various: 6014.7s -> 7659.6s (27.3%)
  3. x86_64-apple-2: 4665.0s -> 4171.6s (-10.6%)
  4. dist-arm-linux: 4966.9s -> 4503.5s (-9.3%)
  5. x86_64-gnu-aux: 6386.8s -> 5905.9s (-7.5%)
  6. x86_64-mingw-2: 6744.0s -> 7194.8s (6.7%)
  7. x86_64-gnu-nopt: 5471.5s -> 5833.5s (6.6%)
  8. x86_64-gnu-stable: 7103.7s -> 6676.9s (-6.0%)
  9. x86_64-gnu-llvm-19-1: 5231.5s -> 5506.9s (5.3%)
  10. dist-x86_64-apple: 7108.3s -> 7476.2s (5.2%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (16244bc): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.1% [-0.1%, -0.1%] 1
Improvements ✅
(secondary)
-0.1% [-0.1%, -0.0%] 5
All ❌✅ (primary) -0.1% [-0.1%, -0.1%] 1

Max RSS (memory usage)

Results (primary -3.1%, secondary 0.1%)

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.0% [3.0%, 3.1%] 2
Improvements ✅
(primary)
-3.1% [-6.8%, -1.2%] 3
Improvements ✅
(secondary)
-0.9% [-1.8%, -0.5%] 6
All ❌✅ (primary) -3.1% [-6.8%, -1.2%] 3

Cycles

Results (primary 1.9%, secondary 2.6%)

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.9%, 3.7%] 18
Regressions ❌
(secondary)
2.6% [0.6%, 4.8%] 18
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 1.9% [0.9%, 3.7%] 18

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 775.816s -> 777.625s (0.23%)
Artifact size: 365.47 MiB -> 365.43 MiB (-0.01%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants