5 ms·

I think qualification of statements is in order. I have heard the definition you gave for ‘zero-overhead’ abstractions in several places. Basically, it is often

I think qualification of statements is in order. I have heard the definition you gave for ‘zero-overhead’ abstractions in several places. Basically, it is often described as features which impose no cost when they are not used. However, Stroustrup uses and advocates another definition, which he discusses in his response to Sutter’s exception proposal linked by a sibling comment. When Bjarne says ‘zero-cost’ he means that some feature incurs no overhead in comparison to equivalent functionality which is hand coded. These two definitions are not equal, Bjarne’s definition (which as the originator of the term [or so I’ve heard], I tend to use as the correct case) is only concerned with asserting the overhead of language constructs compared to specific implementations of the same functionality. There is no requirement that those abstractions and features have no impact on the produced machine code or runtime requirements of not used. I wish zero-overhead meant what you say it means, but it clearly doesn’t.

quietbritishjim 7y ago
Interesting, thanks. I thought I got my definition from Design and Evolution of C++ by Stroustrup but it's a very long time since I read it. (It's also possible that Stroustrup has used that term in different ways over the years, but it's much more likely that I'm just mistaken.)
- throwaway17_17 7y ago
  I think your memory is correct and that Bjarne has probably been loose with the term, I’ll check just to satisfy my curiosity later, but I do know he has been using the version I mentioned several times in the last few years.
  - ncmncm 7y ago
    Some abstractions have no overhead under any circumstances, others have no runtime cost if not used. It is not inconsistent to include the former, trivially.
    - throwaway17_17 7y ago
      But my point in making the distinction is that Stroustrup does not intend to say that 'zero-overhead' is equal to 'no runtime cost if not used'. Stroustrup favors the following: 'zero-overhead' for some feature is equal to 'no runtime overhead above what one would incur from coding the feature yourself. That definition explicitly does not include the concept that 'zero-overhead' features carry no cost when not used. In fact, the entire point of Bjarne discussing what "zero-cost" means in his response to Sutter's exception proposal, is to state that for C++ (which originated the term) "zero-cost"/zero-overhead does not mean that language features do not incur cost by inclusion in the language, like with exceptions. There is a cost to code during runtime if one does not explicitly remove exceptions from the language at compile time. Stroustrup's point is that this built in runtime overhead from having an exception mechanism built into C++ does not violate the language's 'zero-cost' guarantee.
      - voxic11 7y ago
        He actually seems to use the term to refer to both concepts. Quoting him "What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better."
daemin 7y ago
But in that case the equivalent would be manually writing out return codes (or return objects like Expected) and checking errors everywhere. Which at the moment is quite a lot faster than using exceptions. It may not be faster to write but it's quite a lot faster to run, to compile, and uses less disk space/memory for the resulting executable. Ideally I would like to use exceptions as well, since they make the code look a lot neater and clearer, but I cannot justify their use in all places because of these non-zero costs.
- ncmncm 7y ago
  The time to compile exceptions is trivial. Templates and overload sets cost. The time to run exceptions is a lot less than to run failure checks, except in extreme cases as in the synthetic (not to say phony) benchmark presented. If the time spent throwing matters, you're Doing It Wrong. The branch prediction slots that failure checks burn are rare and precious: much bigger than a general purpose register, and much faster than L1 cache. Blowing your branch prediction cache has costs hard to measure, although the perf registers help some. The only substantial cost is object-code file size, and that mainly because precious little effort has been spent to minimize it, because really hardly anybody (i.e., only embedded) cares.
  - daemin 7y ago
    The fact that just enabling exceptions adds a non-zero cost to the runtime of your program, even if the code itself does not use them, means that they are slower than just checking the return values. I've seen values from 5% to 15% slower runtime performance for just enabling exceptions and not even using them. I don't think removing the error checks will give you back those percentages. The problem with proving something like this is you have to build and maintain two separate sets of code for the same project, one that uses exceptions in the correct manner, and another which does error checking to the same degree. Nobody has time to do that for a significant project.

quietbritishjim 7y ago

Interesting, thanks. I thought I got my definition from Design and Evolution of C++ by Stroustrup but it's a very long time since I read it. (It's also possible that Stroustrup has used that term in different ways over the years, but it's much more likely that I'm just mistaken.)

throwaway17_17 7y ago
I think your memory is correct and that Bjarne has probably been loose with the term, I’ll check just to satisfy my curiosity later, but I do know he has been using the version I mentioned several times in the last few years.
- ncmncm 7y ago
  Some abstractions have no overhead under any circumstances, others have no runtime cost if not used. It is not inconsistent to include the former, trivially.
  - throwaway17_17 7y ago
    But my point in making the distinction is that Stroustrup does not intend to say that 'zero-overhead' is equal to 'no runtime cost if not used'. Stroustrup favors the following: 'zero-overhead' for some feature is equal to 'no runtime overhead above what one would incur from coding the feature yourself. That definition explicitly does not include the concept that 'zero-overhead' features carry no cost when not used. In fact, the entire point of Bjarne discussing what "zero-cost" means in his response to Sutter's exception proposal, is to state that for C++ (which originated the term) "zero-cost"/zero-overhead does not mean that language features do not incur cost by inclusion in the language, like with exceptions. There is a cost to code during runtime if one does not explicitly remove exceptions from the language at compile time. Stroustrup's point is that this built in runtime overhead from having an exception mechanism built into C++ does not violate the language's 'zero-cost' guarantee.
    - voxic11 7y ago
      He actually seems to use the term to refer to both concepts. Quoting him "What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better."

daemin 7y ago

But in that case the equivalent would be manually writing out return codes (or return objects like Expected) and checking errors everywhere. Which at the moment is quite a lot faster than using exceptions. It may not be faster to write but it's quite a lot faster to run, to compile, and uses less disk space/memory for the resulting executable. Ideally I would like to use exceptions as well, since they make the code look a lot neater and clearer, but I cannot justify their use in all places because of these non-zero costs.

ncmncm 7y ago
The time to compile exceptions is trivial. Templates and overload sets cost. The time to run exceptions is a lot less than to run failure checks, except in extreme cases as in the synthetic (not to say phony) benchmark presented. If the time spent throwing matters, you're Doing It Wrong. The branch prediction slots that failure checks burn are rare and precious: much bigger than a general purpose register, and much faster than L1 cache. Blowing your branch prediction cache has costs hard to measure, although the perf registers help some. The only substantial cost is object-code file size, and that mainly because precious little effort has been spent to minimize it, because really hardly anybody (i.e., only embedded) cares.
- daemin 7y ago
  The fact that just enabling exceptions adds a non-zero cost to the runtime of your program, even if the code itself does not use them, means that they are slower than just checking the return values. I've seen values from 5% to 15% slower runtime performance for just enabling exceptions and not even using them. I don't think removing the error checks will give you back those percentages. The problem with proving something like this is you have to build and maintain two separate sets of code for the same project, one that uses exceptions in the correct manner, and another which does error checking to the same degree. Nobody has time to do that for a significant project.