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

Revert #43546 "save subobligations in the projection cache" #77325

Closed
wants to merge 1 commit into from

Conversation

ishitatsuyuki
Copy link
Contributor

This effectively reverts #43546 as it seems that it does affect performance more than the PR has anticipated.

This also removes the deduplication code from #48296 as duplications were primarily coming from #43546 and after removing that code it probably doesn't worth paying the cost of using a hash map.

Interestingly, the regression tests introduced in #43546 didn't fail after reverting, but some other tests had breakage. For now I just applied --bless, but I'd like to figure out if it could be a problem later on.

Preliminary perf results confirms that we no longer need deduplication to avoid exponential behavior.

image

This PR will be draft until I figure out the potential breakage.

r? @ghost

Need a perf run. A crater run will help as well to identify potential breakage.

@jyn514
Copy link
Member

jyn514 commented Sep 29, 2020

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Sep 29, 2020

⌛ Trying commit cb7a9c6ac5b49777171397997012564810c86a14 with merge f1391937758145f22ee8b89aba5b57d9766029a6...

@jyn514 jyn514 added I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 29, 2020
Comment on lines 539 to 530
// This is the hottest path in this function.
//
// If we find the value in the cache, then return it along
// with the obligations that went along with it. Note
// that, when using a fulfillment context, these
// obligations could in principle be ignored: they have
// already been registered when the cache entry was
// created (and hence the new ones will quickly be
// discarded as duplicated). But when doing trait
// evaluation this is not the case, and dropping the trait
// evaluations can causes ICEs (e.g., #43132).
Copy link
Member

Choose a reason for hiding this comment

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

Any reason you removed the comment too?

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 dropped it because I also removed the relevant code; that said, I think I deleted too much and some of them still serve as an explanation, so I will restore them later.

@jyn514 jyn514 added the A-trait-system Area: Trait system label Sep 29, 2020
@bors
Copy link
Contributor

bors commented Sep 29, 2020

☀️ Try build successful - checks-actions, checks-azure
Build commit: f1391937758145f22ee8b89aba5b57d9766029a6 (f1391937758145f22ee8b89aba5b57d9766029a6)

@rust-timer
Copy link
Collaborator

Queued f1391937758145f22ee8b89aba5b57d9766029a6 with parent 48cab67, future comparison URL.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (f1391937758145f22ee8b89aba5b57d9766029a6): 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 rollup- to bors.

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

@ishitatsuyuki
Copy link
Contributor Author

ishitatsuyuki commented Sep 29, 2020

Perf summary: improvements on deeply-nested, around -1% for certain (probably assoc-type heavy) cases, and no change for vast of the benchmarks.

I'll continue to try to figure out what might break...

@ishitatsuyuki ishitatsuyuki marked this pull request as ready for review September 30, 2020 11:19
@ishitatsuyuki
Copy link
Contributor Author

I've concluded that the changes in UI test stderr can be justified, as it's not a recursive obligation but just a (unresolvable) self-reference, and such cyclic definitions are unlikely in real world use cases to warrant a specific diagnostic. I did some additional cleanup to fully revert the related changes.

As for potential breakages, I feel it's unlikely to happen given all the tests are passing. Maybe we could get a crater run though.

r? @nikomatsakis since you authored the original changes

@jyn514 jyn514 changed the title Revert #43546 Revert #43546 "save subobligations in the projection cache" Sep 30, 2020
@ishitatsuyuki ishitatsuyuki added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 5, 2020
@nikomatsakis
Copy link
Contributor

@ishitatsuyuki the primary motivation here is performance, or something else?

@ishitatsuyuki
Copy link
Contributor Author

The primary motivation is not performance, probably.

I was looking at the debug! traces of the trait resolver in order to understand something else, but I end up discovering that seemingly simple predicates can resolve to a large number of obligations due to the duplicates, like the case below:

AssocTypeNormalizer: depth=0 normalized <T as num::dec2flt::rawfp::RawFloat>::Bits to <T as num::dec2flt::rawfp::RawFloat>::Bits, now with 20 obligations

So then I spent some time figuring out why does this happen, and the result is this PR. The motivation is not that strong, I just wanted to get rid of these redundant log entries.

@bors
Copy link
Contributor

bors commented Oct 6, 2020

☔ The latest upstream changes (presumably #73905) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

@ishitatsuyuki
Copy link
Contributor Author

ishitatsuyuki commented Oct 8, 2020

Status: get_paranoid_cache_value_obligation is gone with #73905 and I've got a real test failure now, so I need some time to figure out a fix (or to close this if I can't fix it).

@ishitatsuyuki
Copy link
Contributor Author

New discovery: a side effect of this PR is that #76179 would be fixed. I don't know if this is the only way to fix it, though.

@ishitatsuyuki ishitatsuyuki 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 Oct 14, 2020
@ishitatsuyuki
Copy link
Contributor Author

Turns out the (what I think are) regressions was actually caused by #76179, so I filed #78049. Not sure whether the fix of #76179 is correct or accidental.

@ishitatsuyuki ishitatsuyuki added S-waiting-on-review 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 Oct 17, 2020
@jackh726
Copy link
Member

Looks like crater queue for this isn't correct. Both the older check and a newer "run" are queued. Should only be a new "check"

@Dylan-DPC-zz
Copy link

@craterbot abort name=pr-77325

@craterbot
Copy link
Collaborator

🗑️ Experiment pr-77325 deleted!

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels May 21, 2021
@Dylan-DPC-zz
Copy link

@craterbot retry (just to ensure it's in the right state)

@craterbot
Copy link
Collaborator

🚨 Error: failed to parse the command

🆘 If you have any trouble with Crater please ping @rust-lang/infra!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@Dylan-DPC-zz Dylan-DPC-zz added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 21, 2021
@Dylan-DPC-zz
Copy link

@jackh726 removed the older one now :) thanks

@jackh726
Copy link
Member

We don't need a test, just a check

@craterbot abort name=pr-77325-1

@craterbot check

@craterbot
Copy link
Collaborator

🗑️ Experiment pr-77325-1 deleted!

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels May 21, 2021
@jackh726
Copy link
Member

@craterbot check

@craterbot
Copy link
Collaborator

👌 Experiment pr-77325 created and queued.
🤖 Automatically detected try build 7c3a44cf5f95fa5cf164a312bdcf845157af7093
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 21, 2021
@Dylan-DPC-zz
Copy link

aah cool :)

@nikomatsakis
Copy link
Contributor

r? @nikomatsakis

@craterbot
Copy link
Collaborator

🚧 Experiment pr-77325 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot
Copy link
Collaborator

🎉 Experiment pr-77325 is completed!
📊 61 regressed and 11 fixed (163710 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Jun 12, 2021
@ishitatsuyuki
Copy link
Contributor Author

It seems that this indeed introduces problems with trait resolution in some cases:

Variant 1
Variant 2

Something similar happened when I updated the test cases, although all of them were compile-fail tests so I thought that fine and went with a bless. Turns out it isn't OK.

I probably will close this PR, unless there turns out to be an easy enough solution to tackle the regressions above.

@jackh726
Copy link
Member

jackh726 commented Jul 1, 2021

Maybe we should see if #84944 suffers from the same problems as this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-trait-system Area: Trait system I-compiletime Issue: Problems and improvements with respect to compile times. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.