Faster, Easier, Simpler Vectors - David Stone - CppCon 2021

[@pingkai]

At this point, C++ is always solving problem that created by itself, which created so much opportunities for the standard!

[@DerekWoolverton]

The issue with relocate vs move is whether we should take control as programmers, or lean on the compilers to get smart enough to optimize the move-delete idiom.

[@TarikZakariaBenmerar]

How the append has been converted into a set of low level instructions and no function calls ?

[@cemgecgel4284]

compiler magic

[@Bbdu75yg]

Why cant we just malloc an element , and have vector of pointers ? No need of move ,emplace_back ?

[@StanleyPinchak]

Cache locality? No need for additional indirection? Ability to memcpy contents?

[@ragnarlothbrok367]

Sometimes I don't understand a shit

[@broken_abi6973]

where did he find the "stable vector" he referred to? His description seems to be different than boost::stable_vector

[@pervognsen_bitwise]

I think he was referring to the concept more so than any particular implementation. The idea is to reserve a memory range with VirtualAlloc/mmap based on the max capacity and then growing the capacity extends the commit range in place rather than reallocating. Both allocation/deallocation and first-time page access incurs kernel mode transitions (syscalls and page faults, respectively), so it's not something you want for short lived or high churn vectors. But it can be useful if your application has a relatively small handful of big vectors where you need stability and/or performance. (Of course, if you just want stability and performance is not an issue, you can allocate and store the elements outside of the vector itself, as std::unordered_map has to do. The vector would still own those out-of-line elements, so the value semantics would be preserved.)

[@barakap2372]

@@pervognsen_bitwise Do you know any stable vector implementation which has just 1 memory chunk and uses mmap or VirtualAlloc and os-specific functions?

Why there is no call to operator delete in the compiled code from the alternative implementation of vector? (At least in the insert example.)

[@joy1710]

I don't get it why allocator is not part of vector interface. Do all these vector types assume std::allocator?

[@anthonynjoroge5780]

What do you mean? The allocator type is the second template type parameter. For example you can specify your own custom allocator as follows: vector v.

[@JohnDlugosz]

Look for some of the talks from John Lacos. He explains why it is good for types to implement the allocator feature, for enterprise scale software.

[@Roibarkan]

On simple optimizations: m.kzbin.info/www/bejne/qWXan6ifeNyHfbc

[@mr_waffles_the_dog]

thanks!

[@passerby4507]

Welp, the talk didn't deliver what it promised in the title. I'm not sure what I learnt, and I'm not sure in what situation I would recommend someone listen to this.

[@Bolpat]

I had a really hard time to understand _append_from_capacity._ It has a horrible name. It’s not perfect, but _assume_values_in_cpacity_ would even be a better name and that’s not even that great.

[@pervognsen_bitwise]

I've seen this kind of thing called append_uninitialized(size_t n) which just does ensure_capacity(size + n); size += n. You'll find something akin to this in many non-std vector implementations. In Unreal Engine, for example, it's TArray::AddUninitialized.

[@David-fn1rd]

Presenter here, and I agree, the name is horrible. There is work to add this to std::vector, and part of that will include coming up with a (hopefully) great name.

[@__hannibaalbarca__]

Good Programming Language Designed by aGood Mathematicians and to do such good thing like programming in mathematics headaches of assembling many mathematical field in one. Proofing process like in Topology, and we have to separate very close cases when we stadying vectorial spaces and topological spaces after Category theory and abstract algebra and algebraic geometry… this gave to programming designer more conceptual analysis of language.

[@llothar68]

Mathematicians are more often than not terrible programmers.

[@chipcode5538]

Not faster , not easier and not simpler.