It's relative. They are about 1000x slower than fast, good enough hash functions. Dirt slow.
Nobody is talking about password hashes here.
Nobody is talking about password hashes here.
This person's testing has blake3 at 250 cycles for small hashes. It's not a thousand times slower. And for a lot of uses, 250 cycles is plenty fast. That's like one uncached memory access.
That test does mention batching but I don't think it makes a particularly large difference, the paper shows 4 cycles per byte for 64 byte inputs and I don't think they're getting fancy: https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blak...
A modern AES-NI hash is 30.000 MiB/s. That's about 50x faster than blake3 or siphash13. And also not reversible.
When we look at hashes mentioned in this discussion where people are trying to be fast, blake3 is at 3000MB/s when vectorized, and cityhash, murmurhash, and siphash range from 5x faster to 2x slower if I take the smhasher numbers. There's not that much difference.
But also the number we need here is the latency of a small hash, not the max throughput. If blake3 takes 250 cycles for that, how much faster do you think you can go? You can't fit a reasonable hash into 10 cycles. You can't even fit o1hash into 10 cycles. And all of those numbers are pretty fast for most purposes.
AES-NI is a great tool! But isn't that arguing in favor of a crypto hash?
Not 10 cycles, but my polymur-hash can hash any value <= 49 bytes in 21 cycles on an Apple ARM machine: https://github.com/orlp/polymur-hash/.
I think it's a "reasonable hash" too, considering against non-interactive attackers it's provably secure (collision probability bounded up to n * 2^-60.2 for n bytes).