[Suggestion] Add BLAKE3 to comparison table. #450
Labels
No labels
announcement
bug
build
CI
dependencies
documentation
duplicate
enhancement
experience feedback
feature request
github_actions
help wanted
install
invalid
Long-term
optimization
portability
question
target-specific
test issue
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-Cyan4973/xxHash#450
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
good idea, BLAKE3 is supposed to be ridiculously fast by
cryptographically secure hashes-standards,i'm guessing it will end up faster than Murmur3 and slower than City32 (assuming all hashes are only allowed to run on 1 thread, or that the input sizes are small enough that it doesn't matter, and AVX-512 cpu... okay that's a lot of assumptions)
Today I tested City{64,128}, MurMur3{32,128}, and BLAKE3 {portable,sse2,sse4.1,avx2,avx2+MAC} with SMhasher. My CPU doesn't support avx512 so I can't test that feature. I used the C implementation provided by the BLAKE3-team. I did not test xxHash because this was more about seeing how BLAKE3 compares to slower hashes.
BLAKE3 isn't the fastest, but it's really fast for a crypto hash and certainly fast enough for a lot of applications (3.1 GB/s).
BLAKE3 avx2 is about 14% faster than avx2 keyed (MAC), but keyed mode is still faster than MurMur3 x86 32-bit and SipHash (based on the README).
Even though there are faster hashes, BLAKE3 does offer some benefits that others don't. There's no performance hit for longer hashes since BLAKE3 "128" is just using the first 128 bits of a 512 bit hash. It's also crypto hash, so it's secure and it is faster than SipHash so you can use a secure hash with better performance.
Here are the averages of each bulk speed test. Note that these tests were done with an Intel i7-6920HQ CPU @ 2.90GHz on macOS while the tests in the README were done with an Intel i7-9700K on Ubuntu. I tried both -O3 and -O2 and there was no noticeable difference in performance.
The C implementation does not support multi-threading, which isn't important when you're talking about small keys. For completeness though, here is a rough comparison using 'time' on b3sum with 1 and 8 threads and xxhsum 128. The file was 2.7GB and as you can see 8 threads is 5x faster than 1 thread and it is actually faster than xxhsum 128 even though BLAKE3's hash is 4x larger.
Here is the output of the full avx2 test. In the avalanche tests the average worst bias for City128 is 0.719833% and for BLAKE3 it is 0.700542%. As expected there were 0 collisions.
Here is the result for City128, but there's not a lot of difference in the bias.