You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using a non-compatible 8-byte input hasher can increase hash collisions with other input sizes.
There's no need to use a non-compatible 8-byte input hasher if we use a fast non-crypto hash for level 1.
On Intel Haswell CPUs with Go 1.16, my CircleHash functions (which pass Strict Avalanche Criterion, Bit Independence Criterion, and etc.) are able to perform faster than one call to the assignment:
foo:=uint64_a%uint64_b// slower than fast non-crypto hash function that passes SMHasher
I just need to write the README explaining why it should be used instead of current non-crypto fast hashes, add more tests, etc. before making it public (maybe this weekend).
This issue is closed by PR #145. CircleHash64 is faster than foo = uint64_a % uint64_b on Haswell CPU and within about 1 ns per hash on newer Intel CPU models (around 3.5 ns/op for short inputs).
CircleHash64 is currently written to be an easy-to-audit reference, so there's room for optimization if it becomes a bottleneck.
We can potentially skip SipHash for integer key types to gain speed.
Maybe this optimization can be evaluated after OMT is feature complete and we have more test coverage (and fuzzing) in place.
Thanks @ramtinms for mentioning this possible optimization!
The text was updated successfully, but these errors were encountered: