11–20 of 52 posts
The small key performance is very nice. It would be good to have more written about this new hash function, and less misinformed rant about siphash.
> misinformed rant Only siphash fans would say that, and they are very misinformed about the false recommendations from their paper. Prove me wrong.
The small key performance is very nice. It would be good to have more written about this new hash function, and less misinformed rant about siphash.
The small key performance is very nice. It would be good to have more written about this new hash function, and less misinformed rant about siphash.
> misinformed rant Only siphash fans would say that, and they are very misinformed about the false recommendations from their paper. Prove me wrong.
https://github.com/google/highwayhash/issues/28
Still trying to wrap my head around exactly what is being argued... but it's starting to feel like there's something personal going on here, not gonna lie. It's a bit quaint.
(Also a bit curious why Rust is looped into this. It seems like Rust was insecure because the same key was being used for all tables, not really because the hash function was insecure?)
The small key performance is very nice. It would be good to have more written about this new hash function, and less misinformed rant about siphash.
> misinformed rant Only siphash fans would say that, and they are very misinformed about the false recommendations from their paper. Prove me wrong.
Not an expert, would have thought that collision avoidance would be the most important criteria.
There will always be collisions on dynamic workloads. Otherwise you would choose perfect hashes. In the usual programming language case SPOOKY32 has the least collisions, and is pretty fast too. But it has no chance against the small hash functions.
The smhasher speed test doesn't tell you which hash will be the fastest in a hash table with small key lengths, only when used as digest. e.g. for bigger files, db or network blobs. The icache footprint in comparison to all the hash table code is very important.
I beg your pardon? The author seems very confused.
Not an expert, would have thought that collision avoidance would be the most important criteria.
Not in hash tables. There the smaller, the faster. The selection criteria is: not bad (not failing any test), small and fast. Esp. it needs to be inlinable. There will always be collisions on dynamic workloads. Otherwise you would choose perfect hashes. In the usual programming language case SPOOKY32 has the least collisions, and is pretty fast too. But it has no chance against the small hash functions. The smhasher…
Can you explain why? Like what use cases are there where you don't actually care how likely something is to collide, you just want it to be fast?
I've always thought being able to predict the chance of collision to be the most important factor on a hasher. When is it not?
Earlier quoted context omitted.
Not in hash tables. There the smaller, the faster. The selection criteria is: not bad (not failing any test), small and fast. Esp. it needs to be inlinable. There will always be collisions on dynamic workloads. Otherwise you would choose perfect hashes. In the usual programming language case SPOOKY32 has the least collisions, and is pretty fast too. But it has no chance against the small hash functions. The smhasher…
> Not in hash tables. There the smaller, the faster. The selection criteria is: not bad (not failing any test), small and fast. Esp. it needs to be inlinable. Can you explain why? Like what use cases are there where you don't actually care how likely something is to collide, you just want it to be fast? I've always thought being able to predict the chance of collision to be the most important factor on a hasher. When…
The small key performance is very nice. It would be good to have more written about this new hash function, and less misinformed rant about siphash.