[stdlib/Sema/AST] Adopt a commonly used implementation for combining hashes #13056
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
|
/cc @allevato As we'd discussed. |
xwu
changed the title
allevato
reviewed
Nov 24, 2017
| // result = _mixForSynthesizedHashValue(result, a1.hashValue) | ||
| // result = _combineHashValues(result, 2) | ||
| // result = _combineHashValues(result, a0.hashValue) | ||
| // result = _combineHashValues(result, a1.hashValue) | ||
| // } | ||
| // result = _mixInt(result) |
There was a problem hiding this comment.
Do you think it would be worthwhile to eliminate these final calls to _mixInt now? They might be redundant since the seed in your new algorithm starts out well-randomized already.
There was a problem hiding this comment.
They might be redundant now, but I haven't thought it through and it can't hurt, so we can wait on that, maybe?
There was a problem hiding this comment.
That's fine—it might also be good (in a future PR) to have benchmarks against the synthesized hashValue so that future enhancements can be assured to not have performance regressions. (Not that I believe that would be the case here.)
|
This looks good to me—and I agree that the new name is clearer. |
|
@swift-ci please smoke benchmark |
Build comment file:Optimized (O)Regression (1)
Improvement (1)
No Changes (332)
Unoptimized (Onone)Regression (2)
Improvement (3)
No Changes (329)
Hardware Overview |
|
@CodaFi Can you think of others who might be interested in reviewing this before potential merging? |
|
This patch LGTM, but I'll tag Slava too. |
|
@swift-ci please test |
|
Rebased to resolve documentation update conflicts. @slavapestov, LGTY? |
airspeedswift
requested review from
lorentey
and removed request for
airspeedswift
lorentey
approved these changes
Dec 13, 2017
There was a problem hiding this comment.
The new _combineHashValues looks great! LGTM
(It would be nice if we moved the choice of a hash function out of Hashable, so that we would not need to hard-wire any particular combinator here. However, that's clearly out of scope for this PR, and we definitely want to have better hashing until that's done.)
|
@swift-ci please test |
|
Shall we go ahead? |
|
LGTM! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #9619, @allevato left room for adopting a more sophisticated algorithm for combining hashes. This PR adopts a commonly used implementation first described by Hoad and Zobel and since adopted by others, including the Boost C++ library.
While working with the code, I've also renamed the function to
_combineHashValues. As I understand it, the term mix is generally used for(T) -> Toperations that are intended to improve the distribution without creating new collisions, whereas the term combine is more descriptive of(T, T) -> Toperations that inevitably create new collisions (though it may perform some mixing).