3 ms·

smhasher is more up to date: https://github.com/rurban/smhasher?tab=readme-ov-file#smhasher https://github.com/rurban/smhasher?tab=readme-ov-file#smhash...

by pornel 3y ago

matheusmoreira 3y ago
This is really good!! Thanks! The security discussion is particularly interesting, I thought it was the randomization of the initial state of the hash functions which mitigated the hash table collision attacks in the popular programming languages.
zokier 3y ago
I think it is fascinating how big differences there can be depending on which metric you look at. Just goes to show that there is no one size fits all solution, and that you really can squeeze extra perf if you know your application and target hardware. I imagine that if you have some specific fixed length inputs you could do even better
zokier 3y ago
I wonder if there would be difference in wall-clock time if you ran multiple instances of the hash across multiple threads, would the vectorized ones scale differently than scalar ones? With dynamic clocking and weird execution unit arrangements everything is variable
- anonymoushn 3y ago
  If you enable SMT then you might end up using almost all of your possible aesenc's on one of the two threads (for e.g. ahash or meowhash), so you would observe significantly less than 2x the throughput from running 2 threads on the core. If you don't enable SMT then you should get the same results that SMHasher gets. Workloads that are not mostly made of hashing probably won't suffer from this issue even with SMT enabled.
CodesInChaos 3y ago
What's problematic about this table is that some of the "quality problems" are just statistical noise. For example it lists quality problems for sha1-160/sha2-224/sha2-256, which should not have any weaknesses that can be detected by a statistical test. Others seem to be implementation limitations, not flaws in the algorithm itself (e.g. blake3_c's "no 32bit portability").

smhasher is more up to date: https://github.com/rurban/smhasher?tab=readme-ov-file#smhasher https://github.com/rurban/smhasher?tab=readme-ov-file#smhash...

by pornel 3y ago

smhasher is more up to date: https://github.com/rurban/smhasher?tab=readme-ov-file#smhasher https://github.com/rurban/smhasher?tab=readme-ov-file#smhash...

matheusmoreira 3y ago

This is really good!! Thanks! The security discussion is particularly interesting, I thought it was the randomization of the initial state of the hash functions which mitigated the hash table collision attacks in the popular programming languages.

zokier 3y ago

I think it is fascinating how big differences there can be depending on which metric you look at. Just goes to show that there is no one size fits all solution, and that you really can squeeze extra perf if you know your application and target hardware. I imagine that if you have some specific fixed length inputs you could do even better

zokier 3y ago

I wonder if there would be difference in wall-clock time if you ran multiple instances of the hash across multiple threads, would the vectorized ones scale differently than scalar ones? With dynamic clocking and weird execution unit arrangements everything is variable

anonymoushn 3y ago
If you enable SMT then you might end up using almost all of your possible aesenc's on one of the two threads (for e.g. ahash or meowhash), so you would observe significantly less than 2x the throughput from running 2 threads on the core. If you don't enable SMT then you should get the same results that SMHasher gets. Workloads that are not mostly made of hashing probably won't suffer from this issue even with SMT enabled.

CodesInChaos 3y ago

What's problematic about this table is that some of the "quality problems" are just statistical noise. For example it lists quality problems for sha1-160/sha2-224/sha2-256, which should not have any weaknesses that can be detected by a statistical test. Others seem to be implementation limitations, not flaws in the algorithm itself (e.g. blake3_c's "no 32bit portability").