A C++ implementation of a fast hash map and hash set using hopscotch hashing(github.com)
79 pointsby gjvc8 hours ago3 comments
  • jll294 hours ago
    google::dense_hash_map is faster than this new implementation according to their benchmark's diagram (google::dense_hash_map has the lowest runtime of all tested methods).
  • teo_zeroan hour ago
    The concept is very similar to robin hood. In fact most of the performance charts show that the curves of hopscotch and robin hood are very close. I think I'd prefer robin hood as it's well known.
  • mgaunard7 hours ago
    How does it compare to boost unordered flat map?

    Looks like the benchmarks were last updated in 2019.

    • compiler-guy6 hours ago
      https://tessil.github.io/2016/08/29/benchmark-hopscotch-map....

      Has some older benchmarks, including those two.

      • mgaunard3 hours ago
        boost unordered flat map didn't exist in 2016 (nor 2019).
      • jeffbee6 hours ago
        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.

        • utopcell3 minutes ago
          You probably mean absl::flat_hash_map<>.
        • RossBencina5 hours ago
          Abseil Swiss Tables carefully avoids intermediate allocations/copy constructor calls.[1] I'd be wary about inferring underlying algorithm performance from benchmarks that don't explicitly control for these optimisations. (Or maybe everyone is using them and I'm out of touch.)

          [1] https://abseil.io/about/design/swisstables

          • jeffbee4 hours ago
            Algorithmically hopscotch has a better strict worst case whereas swiss tables have a degenerate O(N) lookup. But there are a lot of maps like that. robin_hood::flat_hash_map is very fast but I can create insert sequences under which it will call std::abort, which I feel is ridiculous. But if your hash map isn't exposed to hostile inputs then you might not be concerned.
        • quadrature6 hours ago
          Is there something better than Swiss tables ?.
          • reinitctxoffset5 hours ago
            On modern super wide znver5 or SBSA with full-clock scalar 256 or 512 ALUs / SIMD lanes deep pipelines hight BTB pressure eyc. it's just really difficult to make a priori statements about performance for a given workload.

            absl::flat_hash_map (or folly::F14) are great defaults if you can eat the invalidation semantics.

            But if it's really hot you measure by workload and have infrastructure to flag the right ones in.

            This seems promising. I'll start benching it alongside the other likely lads.

          • szmarczak5 hours ago
            No. Fundamentally it's not possible to be faster.
            • infamouscow5 hours ago
              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.