4 ms·
Not sure why people keep claiming it's the “fastest” when it's far down the list on the SMHasher benchmark list: https://rurban.github.io/smhasher/doc/table.ht
by Sesse__ 2y ago
Not sure why people keep claiming it's the “fastest” when it's far down the list on the SMHasher benchmark list:
https://rurban.github.io/smhasher/doc/table.html https://rurban.github.io/smhasher/doc/table.html
In particular, rapidhash is three times as fast for small inputs and is portable (unlike meow_hash). Plus meow fails one of the SMHasher quality tests.
- palsecam 2y agoRight, Meow is not the best when it comes to small inputs. It shines for large inputs (it’s far up the SMHasher list you linked in this case). It offers a good compromise; it’s not bad (good, even) for both large and small inputs. Granted, rapidhash is quite good on both fronts, too.
- Sesse__ 2y agoWell, it's not even the best AES-NI hash on the list (for large nor small inputs), and it's not passing the quality tests, so why bother?
- nwellnhof 2y agoI wouldn't consider a hash function that relies on 64-bit multiplication truly portable. Its performance will suffer considerably on a 32-bit system. Note that this applies to both Rapidhash and ChibiHash.
- Sesse__ 2y agoWell, even without taking into account that 32-bit systems are increasingly becoming extinct, it's less catastrophic than one might think. You get four muls instead of one and then a little carry propagation; I guess less if you have 32x32 -> 64 muls available? (I haven't thought deeply about it.) Certainly anything that relies on AES-NI would be much worse. But I guess your best shot in Murmur3, then.