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

🛠 improve canonicalization by using a hashing scheme #48417

Closed
nikomatsakis opened this issue Feb 22, 2018 · 14 comments
Closed

🛠 improve canonicalization by using a hashing scheme #48417

nikomatsakis opened this issue Feb 22, 2018 · 14 comments
Labels
A-traits Area: Trait system C-enhancement Category: An issue proposing an enhancement or a PR with one. 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. WG-traits Working group: Traits, https://internals.rust-lang.org/t/announcing-traits-working-group/6804

Comments

@nikomatsakis
Copy link
Contributor

The canonicalization scheme created in #48411 works by first folding types into a canonical form, which is then hashed and interned. This is not necessary, and it shows up in the profiles: we could augment the TypeFolder trait to have a method for hashing as it goes (e.g., a hash_with method, and some hash_ty / hash_region callbacks). Then we can begin by hashing the value-to-be-canonicalized, producing a hash (this would be a kind of "stable hash", hence big enough to be presumed unique). We would then look for an interned value with that hash and return it if found, avoiding all the folding. If no interned value is found, then we would fold and put the resulting value into the interning table. Ideally, this hash can then be kept for later, making the "stable hash" code quite cheap.

(This might actually not make things faster, of course, we would want to measure.)

@nikomatsakis nikomatsakis added A-traits Area: Trait system 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. WG-traits Working group: Traits, https://internals.rust-lang.org/t/announcing-traits-working-group/6804 labels Feb 22, 2018
@nikomatsakis nikomatsakis changed the title improve canonicalization by using a hashing scheme 🛠 improve canonicalization by using a hashing scheme Feb 25, 2018
@nikomatsakis
Copy link
Contributor Author

That said, in all profiles I've looked at, canonicalization doesn't seem to be a hot spot.

@jkordish jkordish added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Apr 23, 2018
@JaimeValdemoros
Copy link

JaimeValdemoros commented May 29, 2018

Hi @nikomatsakis! I'm keen to have a look at this if you don't mind giving me a couple of hints along the way? I have some rust experience but this would be my first time contributing to the compiler.

@JaimeValdemoros
Copy link

JaimeValdemoros commented May 29, 2018

I had an initial go a adding the hash_with method in a branch here: https://github.com/JaimeValdemoros/rust/tree/pre-canonicalization-hashing

@technicalguy
Copy link
Contributor

@JaimeValdemoros Are you still working on this? If you make a pull request (even if it's not "finished" or "ready") then it will be much easier for everyone to see your code (rather than getting GitHub to diff your branch against rust/master directly).

@nikomatsakis nikomatsakis added WG-compiler-nll NLL-performant Working towards the "performance is good" goal labels Jun 26, 2018
@nikomatsakis
Copy link
Contributor Author

I'm tagging this with WG-compiler-nll and NLL-performant since this is also an important issue for non-lexical lifetimes. canonicalization takes about 5% of NLL time.

@JaimeValdemoros
Copy link

Sorry about the delay - I'm still keen give this a shot! I've just made a PR here: #51837 following @technicalguy's suggestion.

@nikomatsakis
Copy link
Contributor Author

@nikomatsakis
Copy link
Contributor Author

Current measurements are showing canonicalization as 11% of NLL check, with the latest optimizations, so this is becoming increasingly relevant.

@technicalguy
Copy link
Contributor

@nikomatsakis I think I have joined Zulip now...yet another chat application!

@nikomatsakis
Copy link
Contributor Author

So, this is a big refactoring, and my measurements suggest that while it would help NLL, it would not make a huge difference. I'm going to remove this from the milestone.

@nikomatsakis nikomatsakis removed this from the Rust 2018 RC milestone Aug 8, 2018
@nikomatsakis nikomatsakis added NLL-deferred and removed NLL-deferred NLL-performant Working towards the "performance is good" goal labels Aug 8, 2018
@nikomatsakis
Copy link
Contributor Author

Perhaps, in any case, this was a bit much too chew at once, I'm going to see if I can break it down into smaller steps.

@pwnorbitals
Copy link

@nikomatsakis is this issue still being worked on ? This sounds like a great refactoring

@technicalguy
Copy link
Contributor

is this issue still being worked on ?

I'm not currently working on it, for one, so go ahead if you're interested!

@jackh726
Copy link
Member

jackh726 commented Jun 24, 2022

Closing. This seems like a lot of work for maybe not so much gain.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-traits Area: Trait system C-enhancement Category: An issue proposing an enhancement or a PR with one. 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. WG-traits Working group: Traits, https://internals.rust-lang.org/t/announcing-traits-working-group/6804
Projects
None yet
Development

No branches or pull requests

6 participants