CppCon 2019: Chandler Carruth “There Are No Zero-cost Abstractions” on HackerTube: recommended by 7 Hacker News commenters across 7 separate months, 2020–2026.
talk · advanced · evergreen
Chandler Carruth argues in a CppCon 2019 talk that C++ has no truly zero-cost abstractions. Using examples like unique_ptr, ABI constraints and compile-time costs, he shows that abstractions cost runtime, compile time or human effort.
HN commenters cite it whenever zero-cost abstraction claims come up, especially for why unique_ptr is not free on some ABIs.
“Chandler presents his point clearly and goes deep enough into the subject.”
20 Hacker News comments link this video. Each one links back to its thread.
Yes, tech talks don't need to be boring and I agree on many points on the post. But also not just 12 slides, more like hundreds of slides. One example I have is Chandler Carruths talk in CppCon 2019 "There Are No Zero-cost Abstrations" ▶ this video Chandler presents his point clearly and goes deep enough into the subject.
in “Tech talks don’t have to be boring” · View on HN
When it comes to the overhead issues of unique_ptr, I always think of this video here: ▶ this video At 26:50 he gets into how this relates to ABI, and how 'fixing' some of this would require a pretty severe ABI change, as well as destructive move semantics, which would require a severe change to how C++ works. I frankly don't understand C++ well enough to fully judge about all of this, but everything he says seems entirely solid, and showcases how unique_ptr is in fact not zero-cost, and can in fact be a significant performance trade-off when you really need that extra bit of performance. > Rust occasionally forces my hand considerably harder (e.g. RC<RefCell<..>> vs std::shared_ptr<>)) in the direction of performance compromise. How so? Is RC<RefCell<T>> more expensive than std::shared_ptr<T>?
in “Scope-based resource management for the Linux kernel” · View on HN
> std::unique_ptr<Foo> doesn't have any overhead over Foo* in code where semantics is the same Not true. And you just refuted yourself by being up the ABI question. You should watch Titus Winters' presentation on this topic where he compiles code using unique_ptr and raw pointers, compares the assembler produced, and explains why unique_ptr has non-zero overhead. The overhead is indeed coming from the ABI. Google has been wanting the next C++ to break ABI but they didn't get enough votes in the standard committee. ▶ this video
in “C++20, How Hard Could It Be” · View on HN
There are no zero cost abstractions. (According to Chandler Carruth, and he makes a convincing point). ▶ this video
in “When zero cost abstractions aren't zero cost” · View on HN
The other time that you saw it was also probably me. It's from this talk, which is about how a large amount of generated protocol buffer code at Google led to a quadratic increase in compile times: ▶ this video . TL;DW: The reasoning is because if you use a distributed build system, then your compile time is gated by the file with the longest compile time (tail latency). The more files you have, the greater chance that one of them takes a long time. When you generate source files, you tend to produce more files than if you didn't. Most users don't use a distributed build system to compile the kernel, so on further thought, in that case compile times probably scale closer to linear with the number of translation units. But wasted cycles are still wasted cycles, and regardless of how exactly compile times scale, you should still consider the cost of longer compile times when you duplicate code. With regards to link time optimization: sophisticated analyses take superlinear complexity: [link] . Disclaimer: I work at Google.
in “The AMD Radeon Graphics Driver Makes Up Roughly 10.5% of the Linux Kernel” · View on HN
With the caveat that I am NOT suggesting this justifies choosing C over C++, I just wanted to mention this talk about how "zero-cost abstraction" is an idealism, not necessarily a reality: ▶ this video That said, I tried to reproduce something similar, and it seems the issue only occurs in my example due to external linkage (adding 'static' fixes it)... but I can't claim this will always resolve the issue: [link]
in “The problem with C” · View on HN
The non-destructiveness of move semantics in C++ is very annoying. It causes for example `std::unique_ptr` to not be a zero-cost abstraction in all cases. See ▶ this video for a nice expose on this.
in “Move, simply” · View on HN
"For 95% of all code that is correct. std::make_* is easy to use and prevents a lot of mistakes, while having no loss of performance." For 95% of code std::unique_ptr has no loss of performance. Perhaps. Just remember that it is not a zero-cost abstraction, the compiler won't always be able to entirely eliminate the overhead: ▶ this video
in “Building a Fast Lock-Free Queue in Modern C++ from Scratch” · View on HN
> Rust makes it possible to safely manage memory without using a garbage collector, probably one of the biggest pain points of using low-level languages like C and C++. In C++, memory management has not been a pain point for many years, and you basically don't need to do it at all if you don't want to. The standard library takes care of it well enough - with owning containers and smart pointers. > And Rust is famous for its optimizations in the style of "zero cost abstractions". No, it isn't that famous for those. The safety and no-UB constraints prevent a lot of that. By the way, C++, which is more famous for them, still struggles in some cases. For example, ABI restrictions prevent passing unique_ptr's via single registers, see: [link] (or see Chandler Carrouth's CppCon 2019 talk: "There are no zero-cost abstractions" ▶ this video )
in “The Compiler Is Your Best Friend, Stop Lying to It” · View on HN
What is often meant by that is "This is a zero run-time cost abstraction". That's a very different thing from a zero cost abstraction. Even if the abstraction actually has a zero run-time cost, which is absolutely not a give, it still has a compile-time cost and a human-time cost. See for example: ▶ this video
in “The Fundamentals of C/C++ Game Programming (2017)” · View on HN
> So you're (primarily?) referring to "cognitive overhead" rather than more usual meaning of overhead as in "runtime overhead" I'm referring to both. The issue is that all that complexity makes it very difficult for programmers to write code that the compiler is consistently able to optimise to (or close to) zero overhead. It can be done with enough work and care but for your average C++ developer, they aren't going to be seeing zero overhead for a lot of the things that C++ generally leads us to assume are zero overhead. > Can you given an example? To copy the link that TwentyPosts provided (which is coincidentally also the first thing that came to my mind, albeit at a different timestamp) ▶ this video . The issues with `unique_ptr` in particular are that: - They force the compiler to generate exception code where maybe there isn't any necessary if you pass them into a function. You can elide this by going through and annotating things that you know can't except with noexcept however most people don't even care about noexcept in the first place and consider it line-noise. - Using move references to unique_ptr instead of pointers adds overhead by forcing the compiler to generate extra memory reads. - Passing by value should be zero cost but it'd require breaking basically every aspect of the C++ ABI to do so. Because of this you still get a double indirection which adds overhead. So your average C++ programmer probably won't do #1 which adds the largest overhead and if you need to
in “Scope-based resource management for the Linux kernel” · View on HN
But the problem with zero-cost abstractions is that even if the runtime cost is 0, the compile time (and the human time) can become quiet large. E.g. ▶ this video
in “Swift Ownership Manifesto” · View on HN
The term comes from C++, where it does have a fairly rigorous definition: [link] Although: ▶ this video I'm not sure whether Rust people consistently use it with precisely the same sense.
in “Kobold, a new web UI crate with zero-cost static DOM” · View on HN
This appears to be incorrect. I have seen a cppcon talk about that. I think it may have been this one: ▶ this video . On the other hand, it is a very, very tiny minority of programmers who have to care about an overhead as low as this. Most of us should not waste one microsecond of our thinking time on this.
in “Writing New System Software” · View on HN
I wonder if it's time to move past that original meaning, or perhaps invent a new catchy term to describe the problem. I'm reminded of this CppCon talk ▶ this video
in “LLVM 13's new pass manager improves Rust's compile times by up to 20%” · View on HN
Not sure if this is sarcastic, but... 1) In dynamic languages, it's not possible to detect whether a function is used or not in the general case. For example, consider string accesses on objects. If the compiler is not sophisticated enough to resolve the set of possible strings at compile time (or such analysis would unacceptably increase compile times), then you can't shake out unused methods on that object. [1] 2) For languages like C and C++, the compiler cannot tree shake because it only knows about a single file at a time (translation unit, to be precise). You would have to rely on link-time optimizations to effectively tree shake, but LTO is not well-supported by all toolchains. Tree shaking also has a cost that I mentioned earlier -- it increases compile times. Both LTO and tree shaking in dynamic languages increase compile times superlinearly [citation needed] wrt. the size of your application. As other commenters have mentioned, it's better to avoid including unnecessary libraries in the first place. There are no cost free abstractions, and that applies to tree shaking as well. ▶ this video [1] For the pedants: yes, I know resolving the possible set of values (stricter than "all possible values for that type") for a variable is undecidable in the general case.
in “What if you knew how computers work? (2015)” · View on HN
This is probably not what was meant, but interestingly unique_ptr actually isn't zero-cost on some ABIs: ▶ this video
in “C++20 has been approved” · View on HN
Re: metamap being zero cost I thought there were no zero cost abstractions in C++? ▶ this video Still, it isn’t RoR or anything JS so it has that going for it.
in “Lithium ranked the highest performance web application platform” · View on HN
> However, do you have any bench / source for std::unique_ptr ? You are the first one I hear giving critics on it. Chandler Carruth talks about this at CppCon 2019 [0]. From a quick review he says part of the reason std::unique_ptr isn't zero-cost right now is: - Objects passed by value (like std::unique_ptr) are passed on the stack instead of in registers, and changing that will be an ABI break - No destructive move means extra temporaries will be created/retained [0]: ▶ this video
in “Comparison of C++17, Go, and Java for a next-generation sequencing tool” · View on HN
The video: ▶ this video I wrote up a reddit post for a possible workaround for removing the overhead. It's standard C++, no ABI break is required. It's not without caveats though: [link]
in “ABI – Now or Never [pdf]” · View on HN