Static size, no deleting. Everyone already knew that you can make faster hash tables when they never need to be resized, but nobody bothers doing that because it is pretty useless or at best niche.
Better to use a few distributions of keys from production-like datasets, e.g., from ClickBench. Most of them will be Zipfian and also have different temporal locality.
Not sure how much value there is in beating Swisstables in very particular cases like this. For specialized cases, one can beat Swisstables by more margin and less effort by using more memory and decreasing load factor, thereby decreasing collisions. You don’t even need SIMD in that case since collisions are rare.
> When looking for an element with hash value h, SIMD technologies such as SSE2 and Neon allow us to very quickly inspect the full metadata word and look for the reduced value of h among all the 15 buckets with just a handful of CPU instructions: non-matching buckets can be readily discarded,
5 comments
[ 2.9 ms ] story [ 19.9 ms ] threadBetter to use a few distributions of keys from production-like datasets, e.g., from ClickBench. Most of them will be Zipfian and also have different temporal locality.
> https://www.boost.org/doc/libs/latest/libs/unordered/doc/htm...
> When looking for an element with hash value h, SIMD technologies such as SSE2 and Neon allow us to very quickly inspect the full metadata word and look for the reduced value of h among all the 15 buckets with just a handful of CPU instructions: non-matching buckets can be readily discarded,