Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I ended up implementing the Fowler–Noll–Vo 1a hash, which is known for trading some quality for increased performance. It was designed to be fast

This is a surprisingly resistant belief. It may have been true once, but today FNV is not even close to being a fast hash function. Check the SMHasher benchmarks:

https://github.com/rurban/smhasher#smhasher

FNV1a almost 2x slower than blake3, a cryptographic hash function! More than 10x slower than modern hashers such as Farm, City, Spooky, ..., all of which have far better statistical quality than FNV1.

There is no good reason to use an FNV function nowadays.



> There is no good reason to use an FNV function nowadays.

Implementation simplicity?

Sometimes you need a hash function in an environment that's not a Real Programming Language.


XxHash has some great benchmarks for various hash functions. FNV is still competitive for small inputs. Most hash functions are built to have high throughput for hashing hundreds of bytes or more. XxHash in particular has an explicit mode switch from "small data" to "big data" sizes around a couple hundred bytes (it varies by platform and compiler).

It's hard to do both small and big data correctly, and FNV is one of the few that optimizes for small data.

For moderately small data, larger than around 4 bytes, xxh3 beats it handily. But for extremely small sizes, FNV is still the winner.

Honestly people should probably just try to switch to xxh3 if performance is a concern, but FNV is certainly competitive for integer-size keys.

https://github.com/Cyan4973/xxHash/wiki/Performance-comparis...


For integer-size keys, a simple integer mixer will perform better than anything.


What is an integer mixer?


A function that mixes the bits of an integer, it's a major component in all modern hash functions (they read a few bytes from the input, add them to the state, mix the state, and continue).

See for example http://jonkagstrom.com/bit-mixer-construction/index.html

When the input is an integer, they're very good hash functions on their own.


The best reason to use FNV is its small codesize, which pays off in icache critical code. such as hash tables. that's why I added the hash tables benchmarks to smhasher.

cycles/map shows you that FNV1a is very good with hash tables, 4x faster than the blake3 monstrosity


Thanks for bringing this up! Someone replied mentioning implementation simplicity, and indeed that was an important factor that I forgot to mention in the post.

Although the most important factor may have been that FNV is just easier to find. Looking for a hash algorithm is hard, the names are weird and opaque and it's hard to find a user friendly ranking or clear directions on how to pick one.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: