aHash VS smhasher

If you find yourself in a situation where you've got some kind of HashMap in your JSON data, try using ahash as the hasher... either via the ready-made ahash::AHashMap or via something like type AHashMap = std::collections::HashMap; if you're using something like serde_with which doesn't like the ready-made one.

aHash claims it is faster than t1ha[1].

The t1ha crate also hasn't been updated in over three years so the benchmark in this link should be current.

[1] https://github.com/tkaitchuck/aHash/blob/master/compare/read...

When I recently went shopping for fast hashes for short strings, I settled on wyhash, but ahash[0] seemed like it would have been better if I had bothered to port it from Rust.

> In that time you can FNV-1a a "short" string.

Not if you read it one byte at a time like in TFA!

It looks like the best FNV for short strings in smhasher[1] is comparably fast to ahash[2] on short strings, but I proposed doing slightly less work than ahash.

> From the top of my head, t1ha, falkhash, meowhash and metrohash are using AES-NI and none of them are particularly fast on short inputs, and at least two of them have severe issues, despite guarding against lots of vulnerabilities, which your construction does not.

For issues like reading past the ends of buffers and discarding the extra values, it would be nice if programmers could arrange to have buffers that could be used this way. I posted a thing for hashing strings of a fixed length though, to compare with the thing for hashing strings of a fixed length in TFA.

[0]: https://github.com/tkaitchuck/aHash/blob/master/src/aes_hash...

[1]: https://github.com/rurban/smhasher/blob/master/doc/FNV1a_YT....

[2]: https://github.com/rurban/smhasher/blob/master/doc/ahash64.t...

Regarding the hashing function: I'll already tried using aHash which sped thing things up but not by a lot.

aHash has a very good comparison doc: https://github.com/tkaitchuck/aHash/blob/master/compare/readme.md (Personally, I use it more to compare non-aHash hashes than to aHash; aHash has no reason to be biased between other hashes, though it does have reason to be biased for itself. I trust their analysis to not be biased, but it's always better to be more sure.)

Hi, i was under the impression that with resolver = "2" cargo would be able to respect the target for the dependencies. Currently i have the problem that while using sqlx, surf and gloo in projects that are in the same workspace – thus sharing a single Cargo.lock – i get a cyclic dependency with aHash that is roughly discussed here

Apparently there is a patch for the SMHasher here which adds support for ahash:

https://github.com/tkaitchuck/aHash/tree/master/smhasher

There are also ahash's own benchmarks here:

https://github.com/tkaitchuck/aHash/blob/master/compare/test...

They use the wyhash Rust crate, so if wyhash itself was updated doing a head to head comparison would boil down to updating the wyhash crate and rerunning ahash's benchmark suite.

The algorithm passes all SMHasher quality tests and uses rounds of AES block cipher internally, so it is quite robust! For comparison XxH3, t1ha0 and many others don't pass SMHasher (while being slower).

Confirmed, I tested it. https://github.com/rurban/smhasher

There's lots of great hash functions out there: some are super fast, like xxhash and highly optimized, others are also super fast umash and based on interesting math ideas from finite fields^1, while maintaining high quality (according to SMHasher). Others are also fast and interesting (tabulation hash, that may sometimes be seemingly universal), one of the main originators of those ideas are Mikkel Thorup^2. Anyway, a couple of years ago I also tried my hand at building hashes and created a few that passed SMHasher (tifuhash ~ a floating point hash, beamsplitter - a seemingly-universal tabulation style hash, and this one discohash - a "more traditional" ARX-based design (addition rotation xor)^3 ).

0: https://github.com/rurban/smhasher/blob/master/xxh3.h

1: https://pvk.ca/Blog/2022/12/29/fixing-hashing-modulo-alpha-e...

2: https://arxiv.org/abs/1505.01523

3: https://eprint.iacr.org/2018/898.pdf https://crypto.polito.it/content/download/480/2850/file/docu...

4: https://en.wikipedia.org/wiki/BLAKE_(hash_function)

Discohash (posted here) is the fastest one I made, it's simple and doesn't rely on any arch-specific optimizations or vector instructions (AVX etc ~ tho I suppose...they could be added? I'm definitely no expert in them, I barely get away with doing the C/C++ implementations!)

The main mixing round function is:

  mix(const int A) {

ubsan, asan, valgrind tests are missing. some do offer symbolic verification of the algo, but not the implementations.

See my https://github.com/rurban/smhasher#crypto paragraph, and

The spinach story reminds me a lot on the false recommendation of siphash for hash table DDOS prevention. https://github.com/rurban/smhasher#security

The authors came up in their widely cited paper with a proper solution to spread the random hash seed into the inner loop, vastly enhancing its security by avoiding trivial hash collision attacks. But a secure, slow hash function can never prevent from normal hash seed attacks, when the random seed is known somehow. esp. with dynamic languages it's trivial to get the seed externally.

Other trivial countermeasures must be used then, which also don't make hash tables 10x slower, keeping them practical.

This is the best, most comprehensive hash test suite I know of: https://github.com/rurban/smhasher/

you might want to particularly look into murmur, spooky, and metrohash. I'm not exactly sure of what the tradeoffs involved are, or what your need is, but that site should serve as a good starting point at least.

Here is a good comparison table, as you can see, BLAKE can perform in secure way much faster than crc32, so my original point, - to use non weak hashes unless you really have a reason/requirement not to do so

smhasher is a great place to testing results for a massive number of hash algorithms.