Uh oh!
There was an error while loading. Please reload this page.
Use SipHash-1-3 for string and integer hashing - #2149
Closed
nikic wants to merge 5 commits into
Closed
Conversation
Hashtable bucket keys are now represented using a union:
union zend_bucket_key {
zend_string *str;
zend_ulong num;
}
The bucket->h value is now a pure hash and no longer doubles as
being the integer key value.
The top bit of bucket->h (HT_IS_STR_BIT) determines whether the
key is a string or and integer. We can do this, because the top
bit will always be 1 after hashtable mask application, so its
value does not influence bucket distribution quality.
The zend_hash_integer() function is a bit of a misnomer -- introducing
integer hashing is not as simple as replacing this function.For testing using a Murmur64 finalizer.
Using dummy key for testing. After changing hash implementation run to avoid full rebuild: touch Zend/zend_hash.c Zend/zend_string.c ext/oci8/oci8.c \ ext/opcache/zend_accelerator_hash.c sapi/phpdbg/phpdbg_bp.c \ sapi/phpdbg/phpdbg_cmd.c Conflicts: Zend/zend_string.h
hikari-no-yume
commented
Oct 13, 2016
Contributor
Oh, this is intriguing. |
nikic
commented
Nov 16, 2016
MemberAuthor
Closing this for now as I don't consider it feasible in the current form. Would require at least some kind of adaptive hash switch for integer keys. |
hikari-no-yume
commented
Nov 16, 2016
Contributor
Hash switch? |
nikic
commented
Nov 16, 2016
MemberAuthor
@TazeTSchnitzel Dynamically switching from djb to siphash based on insert collision threshold, for example. (Other ideas on how to make this work efficiently welcome.) |
hikari-no-yume
commented
Nov 16, 2016
Contributor
Ah, because of the performance hit? That makes sense. |
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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Rebase of an old experiment for SipHash-2-4. Nowadays SipHash-1-3 is considered sufficient for hash tables, so we try that.
Micro-benchmark results for array operations x86-64 (first column with siphash, second column baseline):
As such, we see about 120% regression for operations on non-packed integer hashes and about 50% on non-cached string hashes.