C++Now 2018: You Can Do Better than std::unordered_map: New Improvements to Hash Table Performance
Why Hacker News recommends it
Recommended as a thorough, well-regarded explanation of hash table design tradeoffs and why the standard container is a poor choice.
What it is
Malte Skarupke's C++Now 2018 talk on hash table performance, explaining why std::unordered_map is slow and memory hungry and presenting faster designs, including his bytell hash map.
Recommended by 2 HN commenters across 2 different months, 2021 to 2024.
What Hacker News said
Recommends MauranKilom · 2021-08 · on “JSON for Modern C++ version 3.10.0”
It has the right asymptotic guarantees for a hash map, but beyond that it doesn't have much going for it. The degree to which it emphasizes pointer/iterator stability and arbitrary load factors is not a good tradeoff in almost any practical case (unless you do not care about performance). See [this video] for a more comprehensive discussion, or the sibling threads here.
Recommends ww520 · 2024-10 · on “1BRC Coding Challenge: Nerd Sniping the Java Community”
Many videos on hash table are great. I found this one particularly good. [ [this video] ] C++Now 2018: You Can Do Better than std::unordered_map: New Improvements to Hash Table Performance
Cites MauranKilom · 2021-08 · on “JSON for Modern C++ version 3.10.0”
> some kind of bucket-optimisation (multiple elements per allocation, instead of one element per allocation) should also meet all constraints the standard sets for this type Pretty sure that makes it impossible to implement merge without pointer/iterator invalidation, which is a constraint imposed by the standard ( [LINK] ). > it would be good if the person I originally responded to came out and defended his POV See [LINK] if you want numbers, or for example this talk by the same author [this video] .
Cites JacksonAllan · 2023-11 · on “Factor is faster than Zig”
In my example the table stores the hash codes themselves instead of the keys (because the hash function is invertible) Oh, I see, right. If determining the home bucket is trivial, then the back-shifting method is great. The issue is just that it’s not as much of a general-purpose solution as it may initially seem. In the bad cases, it's really bad. With a different algorithm (Robin Hood or bidirectional linear probing), the load factor can be kept well over 90% with good performance, as the benchmarks in the same repo demonstrate. I’ve seen the 90% claim made several times in literature on Robin Hood hash tables. In my experience, the claim is a bit exaggerated, although I suppose it depends