CppCon 2014: Chandler Carruth "Efficiency with Algorithms, Performance with Data Structures" on HackerTube: recommended by 7 Hacker News commenters across 7 separate months, 2014–2024.
talk · intermediate · evergreen
Chandler Carruth's CppCon 2014 talk on writing fast C++, explaining why data structure choice and memory layout matter more than clever algorithms. It covers why standard containers like unordered_map perform poorly on modern CPUs.
A perennial recommendation for anyone learning performance optimization, cited whenever hash tables, cache behavior or STL containers come up.
“I'm also a big fan of "Efficiency with Algorithms, Performance with Data Structures" by Chandler Carruth at CppCon 2014.”
15 Hacker News comments link this video. Each one links back to its thread.
Strongly agree. That's perhaps less true for the software I work on these days (lapack), but I've seen that so many times over my career. I'm also a big fan of "Efficiency with Algorithms, Performance with Data Structures" by Chandler Carruth at CppCon 2014. ▶ this video
in “Ask HN: How can I learn about performance optimization?” · View on HN
There are many things in the standard C++ library which are named incorrectly (std::string), awkwardly (std::unordered_map) and and implemented inefficiently from the perspective of modern CPUs (same std::unordered_map, which uses linked list for the underlying hash table buckets). See the great talk on CppCon 2014 about those issues - ▶ this video .
in “Std::string half of all allocations in the Chrome browser process” · View on HN
If you haven't already seen it, you'd probably really enjoy Chandler Carruth's "Efficiency with Algorithms, Performance with Data Structures" talk from CppCon 2014: ▶ this video
in “On modern hardware the min-max heap beats a binary heap” · View on HN
Yes, if you write performance sensitive code you have to be very careful with dictionaries. See for example this nice talk by Chandler Carruth ▶ this video
in “Diving into the world of hash tables” · View on HN
Here's a few: - "Tuning C++: Benchmarks, and CPUs, and Compilers! Oh My!" [link] - "Understanding Compiler Optimization" [link] - "Optimizing the Emergent Structures of C++" [link] - "Efficiency with Algorithms" ▶ this video The first one is really good if you've never benchmarked anything in a Linux environment. Or if you otherwise want to learn how to investigate how C++ gets turned into machine code.
in “Why I don't spend time with Modern C++ anymore” · View on HN
STL is not inherently slow per se, some data structures are just not fast on modern CPUs, so they have to be chosen wisely. Here is good talk: ▶ this video .
in “C++ for Games: Performance, Allocations and Data Locality” · View on HN
Also, those allocations imply linked, rather than contiguous, data structures, which (often? always?) imply poor cache interaction, which is a major source of inefficiency. Would love some more perspectives on this, as I've just watched a couple cppcon talks ([0], [1]) and I'm feeling a bit drunk on the kool-aid. [0]: ▶ this video [1]: [link]
in “The Case for Controlled Side Effects” · View on HN
Chandler Carruth's CPPCon talk [0] this year was also great (surprisingly, as I had a fairly low opinion of most of the others). It wasn't better than Mike Acton's [1], but I suspect that it was more actionable for most devs. [0] ▶ this video [1] [link]
in “The Care and Feeding of C++'s Dragons (2013) [video]” · View on HN
But then your objects are scattered all over the address space, which means that objects you’re accessing in sequence are unlikely to be in the same cache line, so you pay a cache miss on every single access. Having (maybe?) more efficient malloc/free in exchange for dramatically increasing the cost of accessing your data is not a good trade-off for most access patterns. See Chandler Carruth’s talk from CppCon 2014: ▶ this video
in “Drop millions of allocations by using a linked list (2015)” · View on HN
This talk seems to me to follow a similar line of thinking to the one I saw presented by Chandler Carruth at the 2014 C++ conference [0]. In the talk he presented a table with (approximately) round-trip-times of various data layers. [0]: ▶ this video
in “Designing far memory data structures: think outside the box” · View on HN
Somewhat interestingly, C++ STL unordered_map is so much slower than it needs to be: ▶ this video Using one of the policy-based data structures instantly gets you about an order magnitude of speedup (for accesses).
in “Benchmarking C++ Sets” · View on HN
Chandler Carruth talks about unordered_map performance[1] in his CppCon 2014 talk "Efficiency with Algorithms, Performance with Data Structures". He endorses most of the other alternatives you mentioned. [1] ▶ this video
in “Diving into the world of hash tables” · View on HN
I think C++'s built in unordered_map has to use chaining due to restrictions on iterators mandated for standard library containers, which is a drag. You've still got to roll your own open addressed container. :( This comes up in one of Chandler Carruth's talks [1]. [1] ▶ this video
in “C++ for Games: Performance, Allocations and Data Locality” · View on HN
Uniformly shitty code is hard to profile. See for example what Chandler has to say about writing good code ▶ this video
in “Searching 20 GB/sec: Systems Engineering Before Algorithms (2014)” · View on HN
I'm pretty curious about this: have memory access patterns and cache awareness become more of a big deal in the past decade or so, or has it only recently reached my awareness? I studied CS in the early 2000s and while I was aware of various trade-offs between contiguous and linked data structures, it's only in the last few years that the importance of cache (and non-"system" languages' widespread flouting of its importance) has really bubbled up in my consciousness. It's certainly likely that I just didn't take the right kinds of classes, or that I did but just missed or failed to really internalize this, but I'm curious if something else is going on. Has the bottleneck increasingly become memory rather than CPU? Have we more thoroughly exhausted other areas of optimization? I was thinking about this while watching a talk[0] given by someone from Google about data structures in the STL, which decried that the standardized specification for `std::unordered_map` more or less forces an implementation to use buckets instead of the more cache-friendly technique of probing. I'm sure that the people who standardized it were very competent, which makes me think that, at least at the time, buckets were thought to be the better implementation. [0]: ▶ this video Edit: Added video link.
in “C++ vs. OCaml: Ray tracer comparison (2005)” · View on HN