Skip to content
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

Fully serialize AdtDef #91924

Merged
merged 3 commits into from
Dec 20, 2021
Merged

Fully serialize AdtDef #91924

merged 3 commits into from
Dec 20, 2021

Conversation

Aaron1011
Copy link
Member

@Aaron1011 Aaron1011 commented Dec 14, 2021

This avoids needing to invoke the adt_def query during
the decoding of another query's result.

Split out from #91919
See #91696 (comment)

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Dec 14, 2021
@rust-highfive
Copy link
Collaborator

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 14, 2021
@Aaron1011
Copy link
Member Author

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

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

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 14, 2021
@bors
Copy link
Contributor

bors commented Dec 14, 2021

⌛ Trying commit 7f7ed6bdec7b4413223ec7b615ca4150c0ed97a6 with merge d3a40c62879ad9441b6cb79f94c654d32481cd91...

@bors
Copy link
Contributor

bors commented Dec 14, 2021

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

@rust-timer
Copy link
Collaborator

Queued d3a40c62879ad9441b6cb79f94c654d32481cd91 with parent 404c847, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (d3a40c62879ad9441b6cb79f94c654d32481cd91): comparison url.

Summary: This change led to very large relevant mixed results 🤷 in compiler performance.

  • Very large improvement in instruction counts (up to -24.9% on incr-unchanged builds of issue-46449)
  • Very large regression in instruction counts (up to 15.7% on incr-full builds of webrender-wrench)

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 led 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

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Dec 14, 2021
@Aaron1011
Copy link
Member Author

Surprisingly, this appears to be a net win for disk usage (at least on the few benchmarks I checked). The increase in the query cache size is less than the decrease in the the size of the dep graph (as there are thousands of fewer query executions being performed).

Copy link
Contributor

@cjgillot cjgillot left a comment

Choose a reason for hiding this comment

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

Should we mark adt_def with cache_on_disk_if { true } for it to benefit from this serialization?

@@ -117,7 +117,7 @@ impl PartialEq for AdtDef {
// `AdtDef`s are always interned, and this is part of `TyS` equality.
#[inline]
fn eq(&self, other: &Self) -> bool {
ptr::eq(self, other)
self.did == other.did
Copy link
Contributor

Choose a reason for hiding this comment

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

Why can't we keep the pointer equality here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Using pointer equality breaks compilation of stage1 libc: I get errors like:

error[E0308]: mismatched types
   --> /home/aaron/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.65/src/int/specialized_div_rem/mod.rs:125:12
    |
125 |     if let Some(quo) = duo.checked_div(div) {
    |            ^^^^^^^^^   -------------------- this expression has type `Option<u64>`
    |            |
    |            expected enum `Option`, found a different enum `Option`
    |
    = note: expected enum `Option<u64>`
               found enum `Option<_>`

I believe we need a 'normal' PartialEq impl in order for interning to work properly, and we need interning because current code is relying on pointers to an AdtDef being unique (since they all currently get allocated through a query).

Copy link
Contributor

Choose a reason for hiding this comment

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

I believe we need a 'normal' PartialEq impl in order for interning to work properly

if you have the time, could you try a perf run which only removes the Hash and Eq impl and does not touch any queries? Would be great to test that before merging this PR

Copy link
Member Author

Choose a reason for hiding this comment

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

I opened #92040 for a perf run with just Hash and PartialEq changed

Copy link
Member

Choose a reason for hiding this comment

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

Looking at the perf results, it seems that the performance impact is acceptable.

This avoids needing to invoke the `adt_def` query during
the decoding of another query's result.
@Aaron1011
Copy link
Member Author

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

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

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 15, 2021
@bors
Copy link
Contributor

bors commented Dec 15, 2021

⌛ Trying commit 70fba90 with merge e89932a1d84ef4783a5137927a85447161a9fbb8...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Dec 15, 2021

💔 Test failed - checks-actions

@bors bors added S-waiting-on-author 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 Dec 15, 2021
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (017ff4233fce7f99092ad20a3e1be45bf3d8e08a): comparison url.

Summary: This change led to very large relevant mixed results 🤷 in compiler performance.

  • Very large improvement in instruction counts (up to -25.0% on incr-unchanged builds of issue-46449)
  • Very large regression in instruction counts (up to 15.8% on incr-full builds of webrender-wrench)

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 led 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

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Dec 17, 2021
@Aaron1011
Copy link
Member Author

Caching the adt_def query on disk seems to have had essentially no effect.

@Aaron1011
Copy link
Member Author

A significant number of people have been hitting the incremental compilation bug that promoted this PR. I'd like to get this merged soon, so that we can unblock the fix in #91919

The only significant regression is webrender-wrench-check. Given that the actual wall-clock diff is very small (0.85 to 1.03 seconds), I think we should merge this.

@Aaron1011 Aaron1011 removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Dec 19, 2021
Copy link
Member

@michaelwoerister michaelwoerister left a comment

Choose a reason for hiding this comment

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

This looks good to me. The regression in webrender is not ideal, but many other benchmarks are improved. The more important thing is that we unblock #91919 though.

@@ -117,7 +117,7 @@ impl PartialEq for AdtDef {
// `AdtDef`s are always interned, and this is part of `TyS` equality.
#[inline]
fn eq(&self, other: &Self) -> bool {
ptr::eq(self, other)
self.did == other.did
Copy link
Member

Choose a reason for hiding this comment

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

Looking at the perf results, it seems that the performance impact is acceptable.

@michaelwoerister
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Dec 20, 2021

📌 Commit 00ce6dc has been approved by michaelwoerister

@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 Dec 20, 2021
@bors
Copy link
Contributor

bors commented Dec 20, 2021

⌛ Testing commit 00ce6dc with merge 84f962a...

@bors
Copy link
Contributor

bors commented Dec 20, 2021

☀️ Test successful - checks-actions
Approved by: michaelwoerister
Pushing 84f962a to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 20, 2021
@bors bors merged commit 84f962a into rust-lang:master Dec 20, 2021
@rustbot rustbot added this to the 1.59.0 milestone Dec 20, 2021
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (84f962a): comparison url.

Summary: This change led to very large relevant mixed results 🤷 in compiler performance.

  • Very large improvement in instruction counts (up to -25.0% on incr-unchanged builds of issue-46449)
  • Very large regression in instruction counts (up to 15.8% on incr-full builds of webrender-wrench)

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

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

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. perf-regression Performance regression. 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.

10 participants