CppCon 2019: Chandler Carruth “There Are No Zero-cost Abstractions”

I love jai because it solved much of the abstraction stuff with the 'using' keyword, allowing for similar semantics without most of the negatives of abstractions like templates and classes.

I used to write code generators for a custom abstraction framework some years ago, not exactly protobuf but something of a similar scale. And the things shown here were one of the points which eventually drove me away from C++, more or less completely, to Rust. There is such too much nuisance, too much stuff which needs to be considered all over the place, and presented in such a way that no user can use the API wrong, and also support all legacy usecases and preferences. It just sucks.

And I would not say that Rust is better _everywhere_. For example, it cannot do plain inheritance, therefore forcing one to construct class structures through composition. It also takes away some freedoms (as long as you avoid unsafe mode). But it has a SANE macro language (however it does not let you do some dirty tricks like with the C preprocessor). But it can help you a lot to create SAFE and FAST multithreaded applicationis, and supports with data types which actually fit various particular usecases (for example, atomic and also non-atomic refcounting "smart pointers").

Always a great talk with Chandler. You'll always find yourself relating to him or in a deep state of introspection as he flips your perspective on your head.

Memory and pointers are not abstractions. Memory is real down the the hardware level, as are pointers to locations in memory

I use to work in place where I was told to refactor everything till every funcion had less than 5 lines.
The code was totaly unredable.

This is a brilliant talk and it does remind me of what Rust is doing to some degree. Really interesting and thought provoking

Now I understand rust

He convinced me to keep writing in C!

Anyone happen to know what font the code was using?

The zero abstraction cost in unique_ptr is the access to the pointer, since unique_ptr manages also the resources this cant be zero cost but that is also not what unique_ptr promises for its zero cost abstraction, allocating and deallocting are expensive things, so I think this is slightly misleading, also its quite bad code if you pass unique_ptr around, this should only happen if you plan on giving ownership away otherwise pass it as reference to functions, this also eliminates the need of nullptr checking. And in my opinion some of the code found in libraries by Google is quite horrendous, no offense.

Indeed, C++ provides brilliant solutions to the problems it itself introduced.

"Abstractions have human cost" lol, if that were true all companies would make their programs in assembler or machine code. Abstractions make writing code faster, easier to write without mistakes. And why wait so much during compilation time, that's such a waste of time, write the entire binary executable file manually instead, that's surely the faster way to do it!

Zero-cost refers to no additional instructions or ram usage. Readability and compile time are not considered cost in that turn of phrase.

I think the point of using Zero-cost Abstractions eg. Unique pointers is that you can't do better yourself (hand code it) if you choose that abstraction.

Author + Title is enough for me to know that this is a thumbs-up :) Now to listen to the wisdom...

about the cost of abstractions...
Core concept from Rich Hickey talks: Inherent complexity vs incidental complexity.
- Yes, you are always replacing some cost with another, but it is NOT just moving cost from one place to another.

He calls generating code the most difficult, the highest cost... in my experience it's the opposite. - Ideally, you want a smart language, though, not generating C++ XD

... idk...

Zero Cost Abstractions Considered Harmful

Finally somebody who thinks about what code does and not just how code looks.

The human cost abstractions are the main reason I eventually moved to C. That language feels infinitely simpler than C++.

How much of this is actually to be handled by the compiler? Not trying to shift blame but a lot of these kind of issues (w.r.t. assembly code) isn't really a language problem.

I think the talk is great. To be fair to the "unique_ptr<T> is zero-cost compared to raw pointers" crowd, they are always emphasizing that it is not common to frequently change ownership. They generally show how terrible it is for performance to overuse passing shared pointers around, and don't focus on passing unique pointers around everywhere because that doesn't happen that commonly, and where it does, it could be a disaster if you misused raw owning pointers, which would be fairly easy to do.

I tested Chandler's unique_ptr example myself, and I did see changes with noexcept, but if I remove noexcept and just add the rvalue references, the noexcept doesnt make a difference.

This talk seems to miss the real meaning of "zero cost" to the standard

Damn. I always tought unique_ptr and small objects are passed in registers. Doh, not true, because because unique_ptr has non-trivial destructor is passed via memory. Very sad. Definitively we need ABI change for this for common standard pointers on which we know move semantics.

Is there a reason to have unique_ptr in method interface if I don't save it there? Isn't it better to get unique_ptr where you need to allocate, but actually use raw pointer? It has the same "safety", but doesn't have performance cost.

So i guess it all boils down to finding the pareto front of the multiobjective cost optimization

Thank you for this talk, I've been trying to tell this to people spreading the gospel of "modern" C++ all the time. A number of them just think the entire point of all c++ coding is to layer incredible levels of abstractions... which I keep telling them actually makes their code harder to parse by humans.

This is why every software engineer should write a compiler at some point as an exercise.
Thinking that things like unique_ptr and raw pointer have the same cost is too common and shows a worrying lack of understanding. Putting blind faith in the compiler to read your mind will only go so far.
Excellent talk!

How is memory an abstraction?

I really find what Chandler is telling very informative, thanks very much. However, I always have a problem with his presentations. It always sounds like everything is bad with C++, he says don't use this and don't use that, OMG it is so bad. I agree fully, hence the arguments are absolutely convincing, but there is almost never any alternative coming. Too many people who watched his presentations now implementing their own maps and unique/shared pointers etc., which are horrible. They invest endless time to implement something sometimes even worse, than in STL, arguing that Chandler said, that the standard implementation is bad. I really had a discussion with somebody, who refused to return unique_ptr from a factory class, going for raw pointer instead, just because he was so impressed by Chandlers talk. The conclusion was, that RAII is bad, because it adds overhead. What is it all about? How should this help C++ to evolve? What about avoiding premature optimization? Why not explicitly presenting this topic as an optimization one? I think it is clear that any abstraction layer costs us somewhere something, but pushing people not to use language features and STL is a wrong way in my opinion.

Would assembly language have zero cost if written well?

Определения понятию «абстракция» не было дано. Пара примеров, мол — это абстракция, и это. Кстати, рассматривать кодогенератор, как абстракцию, очень спорная затея. Далее начинается наебалово: не дав чёткого определения термину, автор начинает про него делать общие утверждения. Которые, опять же, «доказывает» не в общем, а на примерах. В любой момент, на любой неудобный вопрос будет следовать ответ: «А это не абстракция». Удобно. Квантор всеобщности — опасная штука.


Доклад — сумбурная каша в духе статей в жёлтой прессе: «Опасносте! Следи за собой, будь осторожен». Никакой конкретики в плане руководства к действию. Вот какое я знание должен почерпнуть из него? Как должен поменять своё программирование? Начать измерять каждую строку кода по 5-ти параметрам? Даже для марсоходов софт так не пишут. «Ensure that…», «… as much as possible», — это не инженерные рекомендации.

Move destruction is an interesting thought. Rust works the same way. However, current C++ allows us to move member class variables and that would be a breaking change.

This is a good talk.

Liked the Google pun: Larry&Sergey Protobuf Moving Co. (established 1998).

Please explain why enabling arena allocators made your compilation so slow. Generally, I think reality was bent to match the talking points.

Newbie c++ learner here: whatever does he mean generating C++ with python?

I strongly disagree with the idea that it is harder to refactor generated code. If you are generating, say, a design pattern of some kind, it's a lot easier to refactor the generator than actually take the pattern implemented in various places in your code and refactor that to some other pattern.

"Each abstraction must provide more benefit than cost" - That is something to live by, and it's not only applicable to C++.

What did he mean by "2 different metaprogramming in C++" ?

The best talk this year.

I've always understood that Zero-cost abstractions refer to abstractions that add no overhead to a solution built by hand. Especially after optimization, languages with smart enough semantics can have abstractions that are as efficient than attempts at assembly would be (and be way easier to maintain).

always intrigued with this dude's talk;