A C++ implementation of a fast hash map and hash set using hopscotch hashing
11–20 of 26 posts
Re: A C++ implementation of a fast hash map and hash set using hopscotch hashing
#12Re: A C++ implementation of a fast hash map and hash set using hopscotch hashing
#13Re: A C++ implementation of a fast hash map and hash set using hopscotch hashing
#14Earlier quoted context omitted.
https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.... Has some older benchmarks, including those two.
A more recent benchmark is https://martin.ankerl.com/2022/08/27/hashmap-bench-01/ However, it lacks the newer Boost stuff which is very fast. The Hopscotch map was interesting at the time but due to unfortunate timing was immediately outshone by absl::unordered_flat_map A.K.A. "Swiss tables", and there's been even more water under the bridge since then.
Re: A C++ implementation of a fast hash map and hash set using hopscotch hashing
#15The cacheline performance is pretty hard to beat (SIMD optimised linear scan before hopping), which is where all the wins come in the real world.
But basically any of the faster hash maps from absl, boost or folly are going to wreck the standard library in terms of perf
Re: A C++ implementation of a fast hash map and hash set using hopscotch hashing
#16Earlier quoted context omitted.
No. Fundamentally it's not possible to be faster.
This is not true. It is fast as a general purpose hash table, but claiming it's the fastest across all datasets and workloads is silly.
I never claimed so. Please stop stating I said something when I didn't.
> as a general purpose hash table
That's what I claimed. The question IS about hash tables. If you want a hash table of any content, it's impossible to get faster. Unless you check all possible keys at once - only this will get you faster.
Re: A C++ implementation of a fast hash map and hash set using hopscotch hashing
#17----
An point often missed by people who need to/want to do hashing:
In practice, with your real workloads, you can often make do with actually "giving up" on the hasing of some fraction of the elements, whose buckets, neighborhoods and such are already occupied - and instead put those aside for separate out-of-band handling. hash table implementations such as this one (or std::unordered_map and all the rest), absolutely _must_ succeed in inserting your values - and so must always allow for more collisions, resizing etc.
Re: A C++ implementation of a fast hash map and hash set using hopscotch hashing
#18It was 3 years later when I was in college I learned advanced data structures and came into Cuckoo Hashing, then Robinhood hash, and the combination of both Cuckoo and Robinhood hash => Hopscotch hashing
Re: A C++ implementation of a fast hash map and hash set using hopscotch hashing
#19Earlier quoted context omitted.
A more recent benchmark is https://martin.ankerl.com/2022/08/27/hashmap-bench-01/ However, it lacks the newer Boost stuff which is very fast. The Hopscotch map was interesting at the time but due to unfortunate timing was immediately outshone by absl::unordered_flat_map A.K.A. "Swiss tables", and there's been even more water under the bridge since then.
You probably mean absl::flat_hash_map .
Re: A C++ implementation of a fast hash map and hash set using hopscotch hashing
#20My goto these days (and afaik the state of the art) is boost::unordered_flat_set paired with rapidhash for hashing (since the GNU std::hash functions based on murmurhash are ridiculously slow) The cacheline performance is pretty hard to beat (SIMD optimised linear scan before hopping), which is where all the wins come in the real world. But basically any of the faster hash maps from absl, boost or folly are going to…
Doesn't boost::unordered_flat_map use boost::hash by default? How does it compare to rapid hash and std::hash?