Skip to content
0:00 / 0:00

#hashtable#std::unordered_map#robinhoodhashing

C++Now 2018: You Can Do Better than std::unordered_map: New Improvements to Hash Table Performance

CppNow

39K subscribers • 42 videos on Hallway • Conference channel

YouTube
  • Recommended by 2 people: 2 on Hacker News.
  • A classic. People kept recommending it from 2021 to 2024.
  • Presented by Malte Skarupke

Advanced. Deep dive for people who know the field.

62K views8 years ago2 recommendations

Systems programmingComputer scienceC++Performance and optimizationData structures

Malte Skarupke explains why std::unordered_map is slow and presents faster hash table designs, including Robin Hood hashing and SIMD optimizations.

cppnow.org — Presentation Slides, PDFs, Source Code and other presenter materials are available at: cppnow.org/history/2018/talks/ — The hash table is probably the most important data structure. Because of that importance, there is a large zoo of possible implementations with design trade-offs. The standard hash table, std::unordered_map, traded off performance in order to get backwards compatibility with std::map. Which was probably a good choice, but it does leave us with a lot of hash tables that are slower than necessary, while also using more memory than necessary. This talk is about replacements for std::unordered_map. How they work, why they are faster, and when you should choose which. Topics include linear probing with Robin Hood Hashing, Google's new trick of using SIMD instructions to look at 16 elements at a time, and optimizations for node based containers, because they can actually be really fast. I will also talk about recent improvements to hash table performance. Little tricks that shave nanoseconds from table lookup times. In an environment that's already had decades worth of micro-optimizations, it's fascinating to watch as people come up with inventive new ways to keep pushing performance. — Malte Skarupke Malte is an AI programmer at Avalanche Studios in New York. In his free time he likes to optimize algorithms. He blogs at www.probablydance.com — Videos Filmed & Edited by Bash Films: BashFilms.com --- *--* ---

Why it's here

2 people recommend this

What people say. Highly recommended by C++ developers as an excellent, deep-dive explanation of hash table performance and modern alternative designs.

MauranKilomon Hacker News • Recommends

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 link to this video for a more comprehensive discussion, or the sibling threads here.

ww520on Hacker News • Recommends

On “1BRC Coding Challenge: Nerd Sniping the Java Community”

Many videos on hash table are great. I found this one particularly good. [video ] C++Now 2018: You Can Do Better than std::unordered_map: New Improvements to Hash Table Performance

MauranKilomon Hacker News • Mentions

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 link to this video .

JacksonAllanon Hacker News • Mentions

On “Factor is faster than Zig”

…link] Tsl, Martinus, and CC are all Robin Hood tables ( link , link , and link , respectively). Absl (from Google) and Boost are well-known C++ SIMD-based hash tables. Khash ( link ) is, I think, an ordinary open-addressing table using quadratic probing. Fastmap is a new, yet-to-be-published design that is fundamentally similar to bytell ( link to this video ) but also incorporates some aspects of the aforementioned SIMD maps (in particular, it stores a 4-bit fragment of the hash code to avoid most false key comparisons). As you can see, all the Robin Hood maps spike upwards dramatically as the load factor gets high,…

u/jacksaccountonredditin r/C_Programming • Mentions

On “If this isn't the perfect data structure, why?”

This thread has obviously been a real rollercoaster. I responded to one of your other comments, but let me just add some general observations here. From your other comments, it seems like your knowledge of hash tables might be limited to closed-addressing/separate-chaining hash tables. The current frontrunners in high-performance, memory-efficient hash table design all use some form of open addressing, largely to avoid pointer chasing and limit cache misses. In this regard, you want to check our SSE-powered hash tables (such as Abseil, Boost, and Folly/F14), Robin Hood hash tables (such as Martinus and Tessil), or Skarupke (I've recently had a lot of success with a similar design that…