119K views · Oct 1, 2016 · 55:49 · 1 HN recommender · 3 mentions · discussed 2016–2021
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 points people here: Cited as the source for criticism of std::deque and move-constructor pitfalls, and as motivation to write custom data structures.
“I suggest watching this talk”HN comment, 2021
“I suggest watching this talk”
Explains why STL falls short and to write own datastructures
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.
“I'm pretty sure it's in this video”
Source for move constructors de-optimizing std::vector
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
“the standard deque data type is really quite bad”
Chandler criticizes std::deque
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
