Skip to content
HHackerTube.videoSurprise me

CppCon 2016: Chandler Carruth “High Performance Code 201: Hybrid Data Structures"

CppCon 2016: Chandler Carruth “High Performance Code 201: Hybrid Data Structures" on HackerTube: recommended by 1 Hacker News commenter across 1 month, 2016–2021.

CppCon

talk · advanced · evergreen

Open on YouTube

Chandler Carruth's CppCon 2016 talk on designing hybrid data structures for performance. He covers cache locality, working-set size and allocation overhead, and why standard C++ containers fall short.

Why Hacker News recommends it

Cited as the source for criticism of std::deque and move-constructor pitfalls, and as motivation to write custom data structures.

people recommended it
1
separate months
1
strong recommendations
0
discussed on HN
2016–2021
“I suggest watching this talk”
— typon, Aug 2021, in “EASTL: An Alternative C++ Standard Library”

What HN commenters said

3 Hacker News comments link this video. Each one links back to its thread.

typonAug 2021Recommends

I suggest watching this talk: ▶ this video Or pretty much any other by Chandler to understand why the STL sucks and why you should write better datastructures for your own use cases.

in “EASTL: An Alternative C++ Standard Library” · View on HN

04091948Apr 2020Cites it

in CppCon 2016: Chandler Carruth “High Performance Code 201: Hybrid Data Structures"[1] he says: "but the standard deque data type is really quite bad. I wouldn't recommend anyone use it for anything. if you look at the implementation constraints, the constraints placed upon its iterators, and its invalidation constraints, it's painted into a very unpleasant corner and it has very few opportunities to be an efficient data structure." [1] ▶ this video

in “Comparison of C++17, Go, and Java for a next-generation sequencing tool” · View on HN

chubotNov 2016Cites it

The parent was asking the goldilocks question -- was there ever a point where C++ was not too complex like modern C++, e.g. this {} issue, but had enough features (contrast with C, which doesn't have enough features for many applications). I don't think there was such a moment. Apparently move constructors were a de-optimization in the case of std::vector. As far as I remember, it's related to iterator invalidation and move semantics making small-size optimization impossible (e.g. inlining small vectors into the object itself rather than having another pointer and heap allocation). I'm pretty sure it's in this video: ▶ this video Although it's debatable how big a deal this is, it's a good example of the point. People like "C with classes" because they can read the source and kind of figure out what code is generated. They can reason about locality. Although I don't consider myself an expert C++ programmer, if I can't reason about the consequences of move constructors on std::vector, which is a fundamental and relatively simple data structure, then the language is already getting into "surprising" territory. I would have never figured out that de-optimization unless I heard it in a video. On a related note, I wish that return value optimization had better syntax -- that would make move semantics unnecessary in a lot of cases. On the other hand, reasoning about the generated code is already a lost cause because assembly code is so complicated now. We now have to live in a world wher

in “Help me sort out the meaning of “{}” as a constructor argument” · View on HN

Topics & tags