hashtable-bench VS gtl

I believe that when the number of elements is larger than 4 (a rough estimation), the associative linear table won't be faster than ska::flat_hash_map or fph-table with the identity hash function. If you look at the benchmark results, you will find that the average lookup time may well be less than 2 nanoseconds when item number is smaller than one thousand on morden CPUs. For these two hash tables, there are only about ten instructions in the critical path of lookup. And this should be faster than the linear search in a associative table, where there are a lot of branches and comparing instructions. However, you should benchmark it youself to get the real conclusion. This is just a simple analysis on paper from mine. By the way, the associative table can be faster if it is implemented with hardware circuits or SIMD instructions.

gtl library author here. Very nice writeup! Reading it made me think, and I believe I know why gtl::parallel_flat_hash_map performs comparatively worse for high-skew scenarios (just pushed a fix in gtl).

I do this as well in my phmap and gtl implementations. It makes the tables look worse in benchmarks like the above, but prevents really bad surprises occasionally.

Thanks a lot for the great benchmark, Martin. Glad you used different hash functions, because I do sacrifice some speed to make sure that the performance of my hash maps doesn't degrade drastically with poor hash functions. Happy to see that my phmap and gtl (the C++20 version) performed well.

This is very easy to do with the latest version of gtl. And it is extremely efficient, as the caching mechanism uses the parallel hashmap, which internally is divided into N submaps each with its own mutex, reducing mutex contention to a minimum.

AFAIK sparsepp has been dropped entirely in favor of the containers in GTL: https://github.com/greg7mdp/gtl