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

CppCon.org
-
Discussion & Comments: / cpp
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2019
-
C++ is often described as providing zero-cost abstractions. Libraries offer up facilities documented as such. And of course, users read all of these advertisements and believe that the abstractions they are using are truly zero-cost.
Sadly, there is no truth in advertising here, and there are no zero-cost abstractions.
This talk will dive into what we mean by "zero-cost abstractions", and explain why it is at best misleading and at worst completely wrong to describe libraries this way. It will show case studies of where this has led to significant problems in practice as libraries are designed or used in unscalable and unsustainable ways. Finally, it will suggest a different framing and approach for discussing abstraction costs in modern C++ software.
-
Chandler Carruth
Google
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*

[@Attlanttizz]

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

[@Spiderboydk]

Yes. This is a profound and important take-away from the talk.

[@Evan490BC]

Exactly! This is basic Engineering Economics.

[@papa15891]

That doesn't apply to mathematics lmao

[@nickwilson3499]

@@papa15891 why wouldn't it

[@IndellableHatesHandles]

This statement single-handedly obsoletes Python for large projects.

[@mathieu564]

Chandler is one of the better speaker at CppCon: Interesting, entertaining, non-standard and considering real questions.

[@tomaszstanislawski457]

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

[@482F]

Underrated comment

[@alang.2054]

Backwards compatibility!

[@shinobuoshino5066]

As opposed to C that only creates problems without solving any.

[@jvsnyc]

I think the talk is great. To be fair to the "unique_ptr 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.

[@lepidoptera9337]

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

[@monsterhunter445]

I mean how code looks is as important..what.good is hyper performant code if it feels like deciphering hieroglyphics. That being said I do agree sometimes the code needs to be fast without overhead but realistically that isn't always needed and remember code gotta get maintained somehow

[@ASCENDANTGAMERSAGE]

You're in the wrong programming language if you want maximum performance at any cost.

[@jan-lukas]

​@@ASCENDANTGAMERSAGE maximum performance can still only be achieved in assembler, but is so difficult to reach that it's just not worth it at all. If you're doing really low level stuff use C, things that need good performance C++ and nearly anything else Python (if you want to stick to really well established languages I could go on with Rust and so on)

[@edwinontiveros8701]

@@monsterhunter445 that's when wrapping the optimized code in a helper function, with proper naming convention, is in fact the most Zero-cost abstraction there exists. Leave no unrwapped / unnamed procedures, EVER.

[@zechordlord]

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.

[@VivekYadav-ds8oz]

Rust can also move struct members while still leaving the struct intact. However, after that you can't call any methods on the struct, you can only manually manipulate its members.

[@BlairdBlaird]

@@VivekYadav-ds8oz Saying that it "leaves the struct intact" is a bit misleading here: you can't call any method on the struct because the struct *is not* intact, and the compiler knows (and enforces) it: the struct is in a partially moved state, which is in essence a shortcut to exploding the entire thing into separate locals but the compiler does not require explicitly spelling out the explosion.

[@kenneth_romero]

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.

[@shahmiBro1]

always intrigued with this dude's talk;

[@erkinalp]

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

[@BigPapaMitchell]

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.

[@elliott8175]

Which compiler/settings?

[@Bartisim0]

Zero Cost Abstractions Considered Harmful

[@monsterhunter445]

Care to explain why?

[@frydac]

Don't worry, they don't exist

[@sagitswag1785]

??

[@Eyalkamitchi1]

@@monsterhunter445 it's a reference to a paper called "goto considered harmful"

[@mshimzu]

Anyone happen to know what font the code was using?

[@JasonRennie]

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

[@Dominik-K]

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

[@shooshx]

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

[@phil.willoughby]

Possibly templates and the preprocessor

[@notnullnotvoid]

Templates + constexpr.

[@ShalomCraimer]

Template metaprogramming and constexpr, both used at compile-time to decide how the compiler should compile the code. (Although I admit that until he said it, I hadn't linked the word "metaprogramming" to constexpr. Makes sense, I guess.)

[@CristianBidea]

Probably templates and C preprocessor!

[@zvxcvxcz]

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.

[@pedromiguelareias]

"Parse" by humans??? Compilers parse, not humans.

[@JJCUBER]

@@pedromiguelareias humans also parse; look up the definition of the word, it’s not unique to compilers (the definition matches exactly what zvx intended/meant by using the word).

[@yldrmcs]

He convinced me to keep writing in C!

[@jadetermig2085]

And it's not just the examples he showed. People that try to say "well, ACTUALLY, if we modify the compiler in such and such way to fix your unique_ptr example..." don't understand what the real problem is. I have observed this in just about every single aspect of C++. Using std:: algorithms instead of plain old for loops is another way to generate surprising(ly bad) machine code. C is far from perfect but I prefer it to C++ in basically every situation.

[@diltsman]

I have encountered cases at work where the time cost of functions over using goto was sufficiently high that I was unable to use functions. There is a cost, even for very basic abstractions.

[@GeorgeTsiros]

Subroutines ("functions") are rarely a good idea in the executable (recursion is one exception, but i'd prefer by-hand recursion if available) . Subroutines in the source code usually benefit the programmer reading the source code. Whether it's beneficial to have a call depends on many, many things. How often it's called, how many calls to it are there in the code, how long it is, how far it is from the caller, etc.

[@taragnor]

A good compiler should just be able to inline that stuff and remove the function call entirely, while still allowing the abstraction to exist in the source code.

[@VivekYadav-ds8oz]

Yeah, function inlining is a really old optimization problem and I think compilers have gotten sufficiently good at it.

[@AG-ld6rv]

@@taragnor Inlining a function can slow things down in some cases. The rule of thumb is to inline only small functions as that generally is faster most of the time.

[@michaelharrington6698]

@@AG-ld6rv compilers auto inline functions

[@movax20h]

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.

[@anasouardini]

31:20 I don't think switching your focus between functions is any different from switching between blocks of code!

[@thetastefultoastie6077]

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!

[@shrddr]

19:00 soo if the ownership comments are evil, why does the right side have one?

[@mthf5839]

It's evil on the left because you have to read it there in order for the your program to not segfault. On the right, if you ignore the comment, you'll get compile time error, and this comment will hopefully help you solve that error.

[@peterSobieraj]

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.

[@BumboLooks]

OOP bullshit...

[@jadetermig2085]

Sounds like they drank Uncle Bob's Clean Code Koolaid. Hope you got out of there fast.

[@DuRoehre90210]

Yes, and some people also follow the "at most a handful function declarations per header", ending up in hundreds of header files opened/closed for every compilation units. I have also worked with a certain software framework which did lots of "special tricks" with the preprocessor, including actual data management via code generator which created lots of header files - and those had to be included into every unit implicitly, hidden under an "entry point" header. Crazy, probably most of the time the compiler has spent in recalculating all the ifdef-then-undef-else-bla checks and not on the actual code.

[@Quen10-SF]

"funcion ... unredable"

[@kamilziemian995]

1:36 In "CountPattterns" is more "t" than needed. 😉

[@alexreinking]

I always understood the "cost" in "zero-cost abstractions" to be the cost of including them in the language, but not using them. Not the costs of actually using them. Even functions have a small cost of stack traffic, the calling convention limiting usable registers near a call site, etc.

[@gehngis]

Agreed. And Herb's talk confirm this as he defines it as: 1. You don't pay for what you don't use i.e. it is free to include it in the language if you don't use it. 2. It has (run-time) performances similar to what you can do by writing code by hand. So here Chandler Carruth is a bit off topic regarding what "zero cost" means for the C++ standard/committee. However it is likely that some people did misunderstood the C++ meaning of zero cost and did believe that it meant "absolutely zero cost at all". For these people this talk is useful to remind them that this is not the case.

[@notnullnotvoid]

@@gehngis Chandler's talk is all about point 2. "Zero cost" means that runtime perf when using the abstraction should be as good or better than runtime perf without it. In practice this is functionally never the case without optimizations, and rarely ever the case with them.

[@notnullnotvoid]

It's worth noting, of course, that point 1 is also a myth. For example, compiling identical code with `-c++17` (or equivalent) is notoriously slower than with `-c++11`, due to added language features. In other words, you are paying for new features you don't use.

[@taragnor]

@@notnullnotvoid : Well it's not so much compile-time cost as it is performance when your code is actually running. Obviously, compilers with more features will be slower.

[@gehngis]

@@notnullnotvoid Chandler's talk is about build time cost, run time cost and human cost, while point #2 is only about run-time cost. In practice it is possible to have zero overhead run-time cost for abstractions. For instance if you use a template function with T=int you will have the exact same run-time performances than if you write manually a non template version of this function for int. On key point here is that you have to compare the feature provided by C++ vs the same feature implemented manually. So Chandler's comparison of unique_ptr and raw pointers is off topic. You have to compare unique_ptr to something that offers the same thing. As a raw pointers does not handle proper destruction depending if the return value is stored or not, it cannot be compared. Note that if you do not return the unique_ptr you do get the exact same run time performance as a raw pointer. Also the "you don't pay for what you don't use" has also to be understood as run-time cost.

[@jeffvandyke1239]

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).

[@JohKemStYl3]

Did you even listen to the talk?

[@frydac]

I think you refer to zero-overhead abstractions provided by the standard, which have a 'runtime' cost that should be as good as similar hand built abstractions. Bjarne mentions this in his talks from time to time.

[@jadetermig2085]

@@JohKemStYl3 He listened but didn't understand

[@antonlogunov1936]

The best talk this year.

[@Yupppi]

"Probably better than pushing the nail in with your hand" ah, I see the man has written pure C. He goes on about bigger and bigger hammer, but where's the footgun? We came up with abstractions to allow us write easier code with less thinking hard. Until we came up with abstractions that are twice as hard to think about. I think we went wrong somewhere along that line.

[@DmitriNesteruk]

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.

[@zvxcvxcz]

That isn't the comparison. It is not between the code of the generator and the code the generator spat out, it is between the code of the generator and the code you would have written by hand if you didn't have a generator. The handwritten code is almost always much easier to follow. It's almost always easier to reason about a thing than about a meta-thing that needs to spit out something functionally equivalent to that first thing. This is true even for the real world, what is easier, to write a sentence, or to write a sentence generator and get it to spit out the sentences you want? Especially considering the vast number of exceptions that exist to grammar "rules." Sometimes you need the abstraction, it's probably easier to get the generator to put out moderately sensible sentences than to write them by hand if you need to get a million sentences, but yet again, if you want them to be meaningful and eloquent sentences in aggregate... then it's probably better again to write them yourself. I think you're referring to something a bit different, which is that you need to change less code if you have on template vs. 5 functions one for each type. Here, the burden may be intellectual, suppose in your refactoring that you need to support a 6th type that doesn't work like the others, you may need to torture the logic of your templated function significantly to make it generalize to the 6th case. Adding the 6th (or here just a 2nd) function may be straightforward. The actual process of forcing everything to continue meeting the abstractions while you change them is what makes refactoring abstractions more difficult. It is especially difficult on a codebase you didn't write where you don't necessarily know the abstraction structure by heart so it isn't very certain when you make change somewhere if you are breaking an abstraction assumed elsewhere.

[@blenderpanzi]

For which OS where these examples compiled? Because of the talk about calling conventions: Shouldn't that *not* be a problem under Linux, because it does basically what explicit __vectorcall does under Windows (pulling structs passed by value apart and passing the fields in registers)?

[@bjarnestronstrup9122]

Linux, FreeBSD and MacOS use "System V ABI" on x86_64, so it doesn't really matter unless you compile 32bit binaries.

[@garryiglesias4074]

A system call is costly ANYWAY. And maybe I'm wrong, but I think you mess up system ABI calling convention and process internal, compilation-bound calling convention. A compiler can use many different calling convention in the same process, calling convention is stuck to function prototype, usually OS ABI have one specified, and compilation settings may have another default for compiled function.

[@ihatenumberinemail]

​@@garryiglesias4074 I don't think anyone is talking about system calls. The OS ABI still determines what calling convention you'll use by default. Using many different calling convention in the same process is a pain in the arse; Chandler even gave an example of how using both trivial_abi and the x86_64 ABI can cause bugs.

[@tk36_real]

yes but this is only done for types that have trivial destructors otherwise the argument is type memory as per System V ABI spec

[@scorp4770]

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.

[@ZiadHatahet]

He mentions several times in the talk that you have to always benchmark and measure before declaring that a certain piece of code is problematic from a performance standpoint.

[@Spielix]

So maybe your students need to train their listening comprehension skills. Chandler clearly says at some point that he doesn't want people to stop using unique_ptrs, but to understand what they are doing. In the end this is the blessing and course of the internet: Everyone can access these talks which (up to the Back-to-the-Basics talks) are addressed to professionals and maybe even members of the standards committee. In this context talking about problems and being critical should be applauded. While generally content creators do certainly have some responsibility for what they put out, in this case I would say that the problem lies with the students skills of managing the information they get from the internet (or personally at the convention) and not with chandlers talk, as it's intended audience are not mainly students.

[@zvxcvxcz]

I don't think it is against using the STL, but just to know what your abstractions are and when they are worth using. Using an abstraction sometimes is the optimization we shouldn't be doing prematurely. Sometimes it is clearer to just write, for instance, the naive implementation of an algorithm for one type before turning it into a template. This is why it isn't just a code optimization topic, it's also about what people writing code can actually keep straight in their heads at once. Some abstractions are easier to think about than others, e.g. standard String. "Too many people who watched his presentations now implementing their own maps and unique/shared pointers etc., which are horrible. "

[@isodoubIet]

@@ZiadHatahet It kind of doesn't matter what he 'mentions' because the entire point of this talk is that abstractions can add hidden costs and his example is unique_ptr. Regardless of anything he might've said off this main line what most people got out of the talk is that unique_ptr is more expensive than a raw pointer at runtime even though Chandler presented zero measurements. Now all discussions on e.g. ABI have to contend with what is almost certainly an unimportant edge-case (if you're not moving the unique_ptr across a binary's boundaries, your optimizer can get rid of the destructor, and if you are, what's wrong with you?). That was seriously irresponsible on his part IMO.

[@chastitywhiterose]

Would assembly language have zero cost if written well?

[@kuhluhOG]

Probably, but do you have the capabilities to do a (very) large program in Assembly?

[@FaTalCubez]

No because think about the human cost of understanding assembly code.

[@themeeman]

There's a time cost in writing all the assembly, because no matter how good you are its going to take longer than writing a high level language. There is maintainability cost because fixing bugs is insanely hard after you've written all the assembly. There's monetary cost because you have to hire people that can write highly advanced assembly, especially for an insanely complex codebase like at Google, and they will probably have to be paid more. Not to mention, assembly completely non portable, so working with different hardware would require complete rewrites.

[@jan-lukas]

No execution cost, but everything else...

[@xdavidliu]

18:21 pretty sure you can just delete raw_ptr even if its nullptr, since it's specified in the standard that deleting nullptr is a safe no-op

[@VFPn96kQT]

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.

[@gyroninjamodder]

No, unique_ptr should be for managing the lifetime of a block of memory. If a function is just using that memory and has nothing to do with transferring ownership of that block of memory you should just be passing in a raw pointer.

[@rgoswami]

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.

[@krystofjakubek9376]

Kind of. The language is fundamentally just an interface between the humans writing it and the assembly code being generated. In this way when the language introduces a concept thats hard for the compiler to work with its the languages failure as well. For example if the language had no construct of loops and you would have to use raw gotos to do the looping it might be very difficult for the compilet to figure out that that section of the code is isolated loop and perform some loop specific optimalizations on it. Going further if c++ had something akin to move destructors (if the last thing the object does is being moved out of, the move destructor is executed) the given example of passing a unique ptr by value (with noexcept) would indeed provide the desired assembly.

[@kiffeeify]

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

[@simonl1938]

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.

[@Verrisin]

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...

[@Verrisin]

Why on eartth would it be hard to refactor protobuf generated code? It's the easiest. - Write the "template" once, and regenerate everything.... - Everything that is not generated is much harder... You cannot change all the concepts everywhere in one place... - if the generated API surface changes, that has nothing to do with code generation.

[@Verrisin]

EDIT: ok, fine, might problem with dynamic linking, etc....

[@Verrisin]

none of what he says is related to code generation - it's just related to having lots of code, that is not regenerated...

[@Verrisin]

You know what would be worse? If they had to _manually_ update all the serialization and deserialization code... (that was generated instead)

[@Verrisin]

EDIT: ok, ok, I get, it's about generating lots of files that need to be backwards compatible, but use expensive compile time optimization logic ... which caused horrible compile times... ... so, were these build times by the actual generation of the code, or by compiling the generated code? - If the latter, well...

[@nathancrama7352]

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

[@Funcubic]

he just means, that you write a python program that then outputs c++ sourcecode into a new file and then you feed that new file into the cpp compiler.

[@StiegeNZ]

Here's an example framework for generating C with haskell - ivorylang.org/ivory-introduction.html Used with a concurrency framework called tower - github.com/GaloisInc/tower To do awesome things like autopilots - smaccmpilot.org/

[@Lttlemoi]

Exactly that: generating C++ code with a python script during build time. Some examples of where this may be useful: * Include small bits of data into a program as static arrays from a file. e.g. small pieces of text or images that you don't want to load from file at runtime for whatever reason. * Generate constants and structures from a custom description file. Very useful if you need to supply this data to tools written in python or some other scripting language. * Generate serialization boilerplate code (which seems to be the use case for the protocol buffers).

[@intvnut]

At my previous job, I had a number of Perl scripts that generated large volumes of both C++ and assembly code. In some cases, it was generating boilerplate code (e.g. IPC interfaces for connecting classes across processors in a heterogeneous embedded system), in other cases it was generating complex static data structures extracted from a model of the system, and in still others, it was generating actual assembly code for specialized purposes. So, just take that, and replace "Perl" with "Python," and that's what he's talking about.

[@Spiderboydk]

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

[@madpad759]

This is a good talk.

[@Dziaji]

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

[@DuRoehre90210]

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").

[@ZehMatt]

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.

[@yvanpearson7024]

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.

[@AG-ld6rv]

This idea is moving the goalpost. Zero-cost abstraction says whether the abstraction is zero cost in terms of execution time and file size compared to using something lower level. To say a unique_ptr is zero cost, it would have to run as fast as a raw pointer with the same executable size. Similarly, the speaker moved the goalpost by adding the cost on people and on build time into the equation. While all three things matter, the term is about execution speed and file size.

[@naufragio5842]

How is memory an abstraction?

[@Spielix]

He could be thinking about how cache hierachies and everything related to them are hidden by the model of unlimited fast memory. But I may be wrong.

[@kallehed6330]

Now I understand rust

[@Verrisin]

16:45 - NO. It doesn't just move the cost. It replaces it with a DIFFERENT COST in a different place. - That might be much lower, or much higher; in a place that is more expensive, or cheaper. - It is not the same cost moved. - It feels so wrong to my brain... even though he obviously knows this, and doesn't mean it, but it implies the cost remains unchanged, just moved. - Is it zero? Usually not, but with a good system, it can be lower overall. - I'm not arguing against the title.

[@joestevenson5568]

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

[@rontman]

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

[@zvxcvxcz]

He explained why... or are you implying their implementation had some other problem that made it slow instead?

[@isodoublet]

On the unique_ptr woes, this is all more or less useless without timings that show this stuff is actually a problem.

[@jeffwells641]

Somebody missed the entire point of the talk.

[@TheFlamefire]

Just look at this comparison of ASM code: godbolt.org/z/YlANkM No timing required to prove that one is notable slower when called often.

[@DBZM1k3]

Chandler may not have timings but there is a clear increase in instruction size. It may be hard to even see a difference in timings because of the various other factors like hot cache, for example, but the cost is still there. More instructions generally means slower. Over time that would be evident in much larger systems. I think this issue isn't for the majority of people, it will be negligable to non-existent. This problem will be exclusively for time critical applications.

[@sergi0YT]

problem to who and on what scale?

[@davidjulitz7446]

Yes, it is not sure if this is a real problem at runtime (probably it is at least for particular situation depending on CPU's/Cache/RAM constellation and how often it is called). But the statement of the talk stay valid, because it is at least an extra cost in memory for some additional mem move instructions ;).

[@marbles5723]

Maybe raw pointers are the lesser of two evils?

[@jeffwells641]

Depends on what you're doing. If the abstraction is actually buying you something then unique pointers may well be the optimal choice for your code. The point is to work at the necessary level of abstraction, not some arbitrary level of abstraction. Maybe the level of abstraction you need is using raw pointers, maybe you need code generators. It all depends on what you need to do. The idea is to use the lowest level of abstraction that lets you meet your goals. Unnecessary abstraction will cost you somewhere, either in code maintenance, build time, run time, portability, etc.

[@TheFlamefire]

Well: It depends. Add error handling to the raw-pointer code as you get with unique_ptr. Then consider that.

[@taragnor]

Probably only if you're doing very small scale programs, or dealing with a small section of performance critical code. Doing anything large scale and raw pointers introduce a hell of a lot of extra debugging and potential errors. So much so that it takes away coding time that could otherwise be used to optimize your code. The fact that you're devoting extra debugging time to finding raw pointer memory errors likely means that your code will come out slower compared to if you used the smart pointers and used the time to optimize the rest of your code.

[@ABaumstumpf]

​@@taragnor I have recently used quit a lot of raw-pointers as a way of better abstraction and simplifying my code. Performance was of little concern as that is limited by an external database and worse - human interactions. But there the problem also was fundamentally different - create a thread-safe access to a variety of data that normally is supposed to be encapsulated with unique ownership as to allow multiple owners and concurrent manipulation.

[@zvxcvxcz]

Sometimes. For most things the unique_ptr performance difference is insignificant and increased safety is probably worthwhile. His point in that part was that even things that are insignificant are not free and may be significant in some situations so we shouldn't entirely dismiss that small cost.

[@joestevenson5568]

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

[@BumboLooks]

Assembly language doesn't have variables, pointers or type checking. It has addresses and registers (and no type checking). A variable (e.g. in C) is a higher level thing - a way to abstract the location of a piece of data so that you don't have to care if the compiler felt like putting it in a register or in memory.

[@joestevenson5568]

Yes and?

[@smrtfasizmu6161]

"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!

[@monsterhunter445]

Yep it's almost like performance isn't everything.

[@BumboLooks]

Abstractions can make writing code faster or slower. Most of the extra abstract/OOP features in C++ aren't used because they introduce errors and slow programming down. There are plenty of higher-level programming languages that actually do save programmer time. Abstraction is responsible for many fatal programming errors. Companies use obscure time consuming languages (like COBOL and MUMPS) for decades that waste huge amounts of programmer time. This is fine since programmers are cheap and well written code can be used forever on reliable mainframes. Companies wouldn't give two fucks if everyone programmed in C or Assembly. Coding directly in binary is blatant hyperbole from you.

[@DrollerTroller]

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

[@SianaGearz]

There is no recipe to write good code, and there is no straight up definition of good code. If you're uncomfortable with this, you should either become comfortable with that, or software engineering is not for you. This talk isn't supposed to boil down to a single point, but if there was one, it would be that every decision you make presents an engineering trade-off. Maybe you make something safer, but maybe less performant, such as with unique_ptr example. Maybe you make something faster, but more difficult to write and maintain. In principle, this shouldn't even need to be said, the value of this talk is in specific examples that you just have to maybe keep in mind next time you are making such decisions. That you should not follow an implied recipe like "always do this because it's zero cost, so you might as well", but consider the potential drawbacks. Your comment in turn reads like a complaint for complaint's sake. Why hasn't he defined every word used in the talk explicitly? Why doesn't he run a conclusive proof? We're not dealing with mathematical concepts here, but with real-world issues caused by real-world specs, real-world compilers and codebases, and real-world systems. There is nothing to be gained from getting lost in definition lawyering in this instance. I should say though there is an inherent ambiguity and context dependence to an abstraction. I would personally define it as any system that adds expressive power at the cost of specificity. A compiler offers a set of abstractions over the underlying more concrete representation, which is assembler code. Then in turn, code generator that emits C or C++ must also often (but not strictly always) be an abstraction. Assembler might not be an abstraction per se, or maybe it is, as a form of writing and expressive annotation of machine binary code. But what is the most concrete you could get? A time chart of flow of current over all the billions of individual FETs that make up the circuit of the system, perhaps. In turn, machine binary is an abstraction over that, as it allows you to express things linearly for their desired effect which really will happen potentially in a different order or with difficult to predict delays, because you have out-of-order execution, virtualised memory, cache hierarchy, etc. So from the point of view of the machine, assembler is abstract and flow of current is complete. From your point of view, assembler is concrete and C++ is more abstract. Thus the context dependent nature of abstraction. Do you want to continue? Like "what does expressive mean" or "what is power" or "what is specificity", but that would ultimately just be mental masturbation or feigning ignorance.