🛑[stdlib] Flesh out _Hasher API #15939
Closed
Conversation
This file contains 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
lorentey
changed the title
|
@swift-ci please test compiler performance |
lorentey
force-pushed
the
brand-new-combine-harvester
branch
6 times, most recently
from
3849c29 to
4cfaa59
Compare
|
@swift-ci please benchmark |
1 similar comment
|
@swift-ci please benchmark |
Build comment file:Optimized (O)Regression (21)
Improvement (52)
No Changes (349)
Unoptimized (Onone)Regression (52)
Improvement (20)
No Changes (350)
Hardware Overview |
|
Looks pretty good! Except for those UTF-16 hashing benchmarks, of course; oops. |
|
Hm; ASCII String hashing is about 5.5x faster now, while Unicode hashing costs exactly the same. I'm not sure what's going on with |
lorentey
force-pushed
the
brand-new-combine-harvester
branch
from
4cfaa59 to
0836f83
Compare
This was referenced Apr 17, 2018
lorentey
force-pushed
the
brand-new-combine-harvester
branch
from
0836f83 to
e3c9c27
Compare
- String hashing is not inlinable, so it can use _Hasher._core operations directly. - Remove custom buffering. - Make sure we feed the normalized UTF-8 encoding to the hasher; don’t insert extra bytes at the first ASCII->non-ASCII transition. - Add an explicit terminator byte (0xFF).
The new _unsafeHashValue(seed:) requirement allows stdlib types to specialize their hashing when they’re hashed on their own (i.e., not as a component of some composite type). This makes it possible to get rid of discriminator/terminator values and to eliminate most of _Hasher’s resiliency overhead, leading to considerable speedups.
…issue When Set/Dictionary is nested in another Set, the boundaries of the nested collections weren’t correctly delineated in commutative hashing. For example, these Sets all hashed the same: [[1, 2], [3, 4]] [[1, 3], [2, 4]] [[1, 4], [2, 3]] Hash collisions could thus be systematically generated. To fix this, remove collection-level support for one-shot hashing and revert to the previous method of generating hash values. (Set is still able to support one-shot hashing for its members, though.)
This is safe to do with hash(into:), because random hash collisions can be eliminated with awesome certainty by trying a number of different hash seeds. (Unless there is a weakness in SipHash.) In some cases, we intentionally want hashing to produce looser equivalency classes than equality — to let those cases keep working, add an optional hashEqualityOracle parameter. Review usages of checkHashable and add hash oracles as needed.
This makes it easier to understand failure traces in test logs.
Add FIXMEs for potential correctness issues with the existing hashValue definition.
This prototype is not fully implemented, and it relies on specific hash values to not trigger unhandled cases. To keep its test working, define and use a custom hashing interface that emulates hashValue behavior prior to SE-0206.
lorentey
force-pushed
the
brand-new-combine-harvester
branch
from
e3c9c27 to
7af6776
Compare
|
@swift-ci benchmark |
|
I fixed the benchmark regression; ASCII hashing is still 5.5x faster, while Unicode hashing is largely unchanged (with a minimal improvement). I expect the benchmarks will be much better now. This PR is getting too large; I think I'll split it into smaller chunks that can be reviewed separately. |
|
@swift-ci please test |
|
Build failed |
lorentey
changed the title
Build comment file:Optimized (O)Regression (15)
Improvement (49)
No Changes (358)
Unoptimized (Onone)Regression (13)
Improvement (64)
No Changes (345)
Hardware Overview |
This was referenced Apr 19, 2018
|
With #17396, all pieces of this PR have landed. Closing. |
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.
Update
_HasherAPI names to match those proposed in SE-0206, and implement missing functionality.