33 ms·

Out of interest (its decades since I last used C++) - do C++ exceptions cause an overhead generally or only if they are thrown?

monocasa 7y ago
SJLJ have overhead (but no one really uses that anymore). The vast majority of modern envs (which boil down to DWARF and MSVC) only have overhead when thrown.
- DerDangDerDang 7y ago
  Theoretically true, but colleagues of mine have done benchmarks showing MSVC has a slight overhead with exceptions enabled, even if none are thrown. Worth benchmarking yourself if you need to be sure.
  - monocasa 7y ago
    Is that recorded somewhere? The benchmarks I've done have been pretty all over the place and seem to be around jiggling the I$ alignment. Sometimes helps, sometimes hurts.
    - fwsgonzo 7y ago
      I have a site for testing these things: https://droplet.fwsnet.net/ https://droplet.fwsnet.net/ I wrote some tests, not sure if they are perfect: #include <stdexcept> volatile int i = 1; __attribute__((noinline)) int test() { return i; } int main() { if (test() == 0) throw std::runtime_error(""); return 0; } ====> Instruction count: 612 Memory usage: 116 KB, top: 116 KB Compile time: 745326 micros Execution time: 149 micros Binary size: 98 KB The above is with exception, below is without: volatile int i = 1; __attribute__((noinline)) int test() { return i; } int main() { if (test() == 0) return -1; return 0; } ====> Instruction count: 251 Memory usage: 16 KB, top: 16 KB Compile time: 441626 micros Execution time: 53 micros Binary size: 3 KB Just remember to pick newlib as the target, as that is the thinnest, and the no-exceptions variant will be only 16kb.
      - monocasa 7y ago
        Using full process startup/shutdown for a microbenchmark is a bit specious. Also, what are your compile flags? godbolt shows a pretty big difference with -O2.
      - fwsgonzo 7y ago
        To monocasa, which I can't reply to: I agree completely, it really does run everything from start to finish. Sometimes that's what you want, and sometimes you don't. I could break on main as an option, and then start the benchmarking after main. It would include teardown, unless you call _exit() at the end of main. The compile flags are -O2, no linker GC.
    - DerDangDerDang 7y ago
      I'm afraid not sorry. Though it probably wasn't a great benchmark. They were only investigating whether enabling exceptions has a cost if not thrown on MSVC. So a single example where there was a penalty was enough to cast doubt on exception usage. Enough that nobody felt like sticking their neck out to fight the cause, anyway ;)
- saagarjha 7y ago
  Well, there’s a slight code size overhead.
- benibela 7y ago
  FreePascal uses SJLJ, at least on Linux
bregma 7y ago
With the more common modern compilers (Microsoft, GCC, LLVM, ICC, many others) there is zero runtime overhead to programming with exceptions unless they are thrown. This is possible because the unwind information is stored externally to the function code. There is still an additional overhead in terms of space, since the .eh_frame (or equivalent) sections need to loaded and possibly relocated by the linkloader at program startup, although that's minimal work if addresses are in self-relative tables like in the ARM EABI. The alternative to having the exception-handling code out of line is, of course, handling all exceptional conditions in line, which not only makes the code harder to read but makes the generated object code bigger and, if it fails to fit in a cache line or causes unwholesomely large numbers of branch evaluations (see spectre and meltdown) results in slower or more insecure code. The real answer to C++ exceptions is the classic C-style programming where all errors are just ignored. Of course, no amount of reasoning or hard data survives in the face of religious belief, and 80% of programmers out there are part of one cargo cult or another, so carry on with what you were doing. It's probably good enough.
- notacoward 7y ago
  > classic C-style programming where all errors are just ignored That's a mischaracterization of most C code written by professionals, because (with appropriate compiler flags) return codes have to be explicitly ignored. Contrast with languages where most functions don't even have a return code, and the compiler/interpreter doesn't complain about failing to catch possible exceptions. I see this a lot in Python code (which I generally like and have liked since 1.5 BTW), a bit less so in C++, etc. Even "elite" programmers in those languages tend to be sloppy that way, which I rarely see in C programmers with more than a couple of years' experience.
  - bregma 7y ago
    > That's a mischaracterization of most C code written by professionals I've been a professional programmer for 40 years, much of that in C. I've seen a lot of code, some of it in production in critical systems for many years. It is not a mischaracterization, it is a description of the state of the art.
kats 7y ago
Only when they are thrown. (for reference: https://www.youtube.com/watch?v=COEv2kq_Ht8 https://www.youtube.com/watch?v=COEv2kq_Ht8)
mhh__ 7y ago
Yes and no. I haven't measured the exact effect of this, but - although that if the wind doesn't throw the ship doesn't slow - having an exception-al path through the code will stop some compiler optimizations. I have seen this first hand but I also remember Walter Bright mentioning it either here or elsewhere. If this is definitely the case maybe someone could chime in why exactly (I've never fiddled with a backend in the right places to deal with exceptions)
- jcranmer 7y ago
  By default, every function call--including external function calls--can cause an exception to be thrown. Any unresolved function call now causes an extra edge in the control-flow graph that goes to what is effectively a return in the function. This extra edge is also harder to manipulate for normal CFG optimizations (e.g., splitting critical edges or duplicating nodes).
- gmueckl 7y ago
  Yes, I also was pretty oblivious to this until Walther Bright mentioned it in the D forums a few months back. I went back and did some simple tests with the compiler explorer and sure enough, I got some extra overhead in the generated code with exceptions enabled as soon as the compiler could not prove the absence of exceptions.

monocasa 7y ago

SJLJ have overhead (but no one really uses that anymore). The vast majority of modern envs (which boil down to DWARF and MSVC) only have overhead when thrown.

DerDangDerDang 7y ago
Theoretically true, but colleagues of mine have done benchmarks showing MSVC has a slight overhead with exceptions enabled, even if none are thrown. Worth benchmarking yourself if you need to be sure.
- monocasa 7y ago
  Is that recorded somewhere? The benchmarks I've done have been pretty all over the place and seem to be around jiggling the I$ alignment. Sometimes helps, sometimes hurts.
  - fwsgonzo 7y ago
    I have a site for testing these things: https://droplet.fwsnet.net/ https://droplet.fwsnet.net/ I wrote some tests, not sure if they are perfect: #include <stdexcept> volatile int i = 1; __attribute__((noinline)) int test() { return i; } int main() { if (test() == 0) throw std::runtime_error(""); return 0; } ====> Instruction count: 612 Memory usage: 116 KB, top: 116 KB Compile time: 745326 micros Execution time: 149 micros Binary size: 98 KB The above is with exception, below is without: volatile int i = 1; __attribute__((noinline)) int test() { return i; } int main() { if (test() == 0) return -1; return 0; } ====> Instruction count: 251 Memory usage: 16 KB, top: 16 KB Compile time: 441626 micros Execution time: 53 micros Binary size: 3 KB Just remember to pick newlib as the target, as that is the thinnest, and the no-exceptions variant will be only 16kb.
    - monocasa 7y ago
      Using full process startup/shutdown for a microbenchmark is a bit specious. Also, what are your compile flags? godbolt shows a pretty big difference with -O2.
    - fwsgonzo 7y ago
      To monocasa, which I can't reply to: I agree completely, it really does run everything from start to finish. Sometimes that's what you want, and sometimes you don't. I could break on main as an option, and then start the benchmarking after main. It would include teardown, unless you call _exit() at the end of main. The compile flags are -O2, no linker GC.
  - DerDangDerDang 7y ago
    I'm afraid not sorry. Though it probably wasn't a great benchmark. They were only investigating whether enabling exceptions has a cost if not thrown on MSVC. So a single example where there was a penalty was enough to cast doubt on exception usage. Enough that nobody felt like sticking their neck out to fight the cause, anyway ;)
saagarjha 7y ago
Well, there’s a slight code size overhead.
benibela 7y ago
FreePascal uses SJLJ, at least on Linux

bregma 7y ago

With the more common modern compilers (Microsoft, GCC, LLVM, ICC, many others) there is zero runtime overhead to programming with exceptions unless they are thrown. This is possible because the unwind information is stored externally to the function code. There is still an additional overhead in terms of space, since the .eh_frame (or equivalent) sections need to loaded and possibly relocated by the linkloader at program startup, although that's minimal work if addresses are in self-relative tables like in the ARM EABI. The alternative to having the exception-handling code out of line is, of course, handling all exceptional conditions in line, which not only makes the code harder to read but makes the generated object code bigger and, if it fails to fit in a cache line or causes unwholesomely large numbers of branch evaluations (see spectre and meltdown) results in slower or more insecure code. The real answer to C++ exceptions is the classic C-style programming where all errors are just ignored. Of course, no amount of reasoning or hard data survives in the face of religious belief, and 80% of programmers out there are part of one cargo cult or another, so carry on with what you were doing. It's probably good enough.

notacoward 7y ago
> classic C-style programming where all errors are just ignored That's a mischaracterization of most C code written by professionals, because (with appropriate compiler flags) return codes have to be explicitly ignored. Contrast with languages where most functions don't even have a return code, and the compiler/interpreter doesn't complain about failing to catch possible exceptions. I see this a lot in Python code (which I generally like and have liked since 1.5 BTW), a bit less so in C++, etc. Even "elite" programmers in those languages tend to be sloppy that way, which I rarely see in C programmers with more than a couple of years' experience.
- bregma 7y ago
  > That's a mischaracterization of most C code written by professionals I've been a professional programmer for 40 years, much of that in C. I've seen a lot of code, some of it in production in critical systems for many years. It is not a mischaracterization, it is a description of the state of the art.

kats 7y ago

Only when they are thrown. (for reference: https://www.youtube.com/watch?v=COEv2kq_Ht8 https://www.youtube.com/watch?v=COEv2kq_Ht8)

mhh__ 7y ago

Yes and no. I haven't measured the exact effect of this, but - although that if the wind doesn't throw the ship doesn't slow - having an exception-al path through the code will stop some compiler optimizations. I have seen this first hand but I also remember Walter Bright mentioning it either here or elsewhere. If this is definitely the case maybe someone could chime in why exactly (I've never fiddled with a backend in the right places to deal with exceptions)

jcranmer 7y ago
By default, every function call--including external function calls--can cause an exception to be thrown. Any unresolved function call now causes an extra edge in the control-flow graph that goes to what is effectively a return in the function. This extra edge is also harder to manipulate for normal CFG optimizations (e.g., splitting critical edges or duplicating nodes).
gmueckl 7y ago
Yes, I also was pretty oblivious to this until Walther Bright mentioned it in the D forums a few months back. I went back and did some simple tests with the compiler explorer and sure enough, I got some extra overhead in the generated code with exceptions enabled as soon as the compiler could not prove the absence of exceptions.