Closed kirillt closed 8 months ago
Different parameters and different cores numbers should be tested in the benchmark.
This benchmark presents different results:
Hash function MiB/sec cycl./hash cycl./map size Quality problems blake3_c 1288.84 357.69 582.89 (6) no 32bit portability crc32 383.12 134.21 257.50 (11) 422 insecure, 8590x collisions, distrib, PerlinNoise crc32_hw 6244.38 41.23 226.80 (2) 653 insecure, 100% bias, collisions, distrib, BIC, machine-specific (SSE4.2/NEON) crc32_hw1 7569.29 49.07 233.75 (3) 671 insecure, 100% bias, collisions, distrib, BIC, machine-specific (x86 SSE4.2) crc64_hw 6143.62 40.48 223.13 (2) 652 insecure, 100% bias, collisions, distrib, BIC, machine-specific (SSE4.2/NEON)
We use crc32fast crate to generate
ResourceId
. It was one of the fastest hash functions 3 years ago, when blake3 was invented.Official metrics:
Blake3, AWS c5.metal, 16 KiB input, 1 thread: 6866 MiB/s
CRC32, unknown env and run parameters: baseline: 1499 MiB/s, pclmulqdq: 7314 MiB/s
Let's create a small benchmark to compare them in same environment, with same parameters.
Even if
blake3
is same performant ascrc32
, it would be worth updatingarklib
, becauseblake3
is cryptographic hash function and it means no collisions in the index.