3 ms·

Are you sure? Single threaded 18-16ms (boost::LEAF) vs 19-23ms (exceptions) A better comparison is found here: https://lordsoftech.com/programming/error-co

Are you sure? Single threaded 18-16ms (boost::LEAF) vs 19-23ms (exceptions) A better comparison is found here: https://lordsoftech.com/programming/error-codes-are-far-slower-than-exceptions/ https://lordsoftech.com/programming/error-codes-are-far-slow... > TL;DR On modern 64-bit PC architectures, C++ exceptions only add unreachable code with destructor calls into functions and their effect on performance is below 1%, but such low values are difficult to measure. Handling rare errors with return values requires additional branching that slows down the program in realistic scenarios by about 5% and are also less convenient. If an exception is actually thrown, stack unwinding costs about 2 µs per stack frame. 5% cost to using error codes. In exchange for that 5% you don't fall off a performance cliff if you hit a bunch of errors unexpectedly, and can confidently use them in hot paths and on CPUs with multiple cores. I'll take the lower perf complexity and greater perf robustness of error codes any day. Reliability and predictability is more important to me than a 5% perf cost.

kllrnohj 5y ago
Your "better comparison" finds that error codes are slower than exceptions? It's right there at the top in bold even if you don't want to read the whole thing: > TL;DR On modern 64-bit PC architectures, C++ exceptions only add unreachable code with destructor calls into functions and their effect on performance is below 1%, but such low values are difficult to measure. Handling rare errors with return values requires additional branching that slows down the program in realistic scenarios by about 5% and are also less convenient. Also I see you "cherry picked" your counter example using the sqrt test, which is less influenced by per-call overhead. Using instead the fib test, which is basically just a test of call overhead, we get instead: 12ms-14ms (exceptions) vs. 22-23ms (boost::LEAF) Both the paper & your link are in agreement - exceptions are faster than error return values. > 5% cost to using error codes. In exchange for that 5% you don't fall off a performance cliff if you hit a bunch of errors unexpectedly, and can confidently use them in hot paths and on CPUs with multiple cores. You also get more fragility since error handling is now manual. I'd rather have performance and reliability, which only exceptions can provide. They don't provide that today thanks to the global mutex, but the point of the paper & related explorations is that that both can be fixed, and that fixing it provides a superior performing solution. And a more reliable one. Unless you're arguing that it's better to just always have a 5% performance tax & manual, error-prone error handling? We shouldn't attempt to fix the toolchain at all? The paper isn't arguing that people should use exceptions today. The paper is arguing that exceptions should be fixed so that they can be used in the future.
- randyrand 5y ago
  > Unless you're arguing that it's better to just always have a 5% performance tax & manual, error-prone error handling? Exceptions today are untenable for a library author because you don't know which input data your callers will use, and therefore can't predict how often errors will be thrown. Ideally we'd fix c++ with better manual propagation of errors and compiler warnings, like Rust or Zig. Even if the global mutex is fixed, the single threaded perf numbers are terrible if you hit a bunch of unexpected errors. That seems unfixable. I'd rather have 5% slower code, than 5% faster code with occasional 1000% slow downs (in the worst case).
  - kllrnohj 5y ago
    > I'd rather have 5% slower code, than 5% faster code with occasional 1000% slow downs (in the worst case). Perhaps, but that's a strawman through & through. C++ exceptions don't have that performance cliff when thrown, per both the paper in the OP & in your link. They are fairly cheap to throw assuming a single-threaded application. That is, the fib example with 10% failure rate has the same performance using exceptions & using Boost::LEAF. Unless you're calling it "unfixable" because there isn't actually anything to fix in the first place...

kllrnohj 5y ago

Your "better comparison" finds that error codes are slower than exceptions? It's right there at the top in bold even if you don't want to read the whole thing: > TL;DR On modern 64-bit PC architectures, C++ exceptions only add unreachable code with destructor calls into functions and their effect on performance is below 1%, but such low values are difficult to measure. Handling rare errors with return values requires additional branching that slows down the program in realistic scenarios by about 5% and are also less convenient. Also I see you "cherry picked" your counter example using the sqrt test, which is less influenced by per-call overhead. Using instead the fib test, which is basically just a test of call overhead, we get instead: 12ms-14ms (exceptions) vs. 22-23ms (boost::LEAF) Both the paper & your link are in agreement - exceptions are faster than error return values. > 5% cost to using error codes. In exchange for that 5% you don't fall off a performance cliff if you hit a bunch of errors unexpectedly, and can confidently use them in hot paths and on CPUs with multiple cores. You also get more fragility since error handling is now manual. I'd rather have performance and reliability, which only exceptions can provide. They don't provide that today thanks to the global mutex, but the point of the paper & related explorations is that that both can be fixed, and that fixing it provides a superior performing solution. And a more reliable one. Unless you're arguing that it's better to just always have a 5% performance tax & manual, error-prone error handling? We shouldn't attempt to fix the toolchain at all? The paper isn't arguing that people should use exceptions today. The paper is arguing that exceptions should be fixed so that they can be used in the future.

randyrand 5y ago
> Unless you're arguing that it's better to just always have a 5% performance tax & manual, error-prone error handling? Exceptions today are untenable for a library author because you don't know which input data your callers will use, and therefore can't predict how often errors will be thrown. Ideally we'd fix c++ with better manual propagation of errors and compiler warnings, like Rust or Zig. Even if the global mutex is fixed, the single threaded perf numbers are terrible if you hit a bunch of unexpected errors. That seems unfixable. I'd rather have 5% slower code, than 5% faster code with occasional 1000% slow downs (in the worst case).
- kllrnohj 5y ago
  > I'd rather have 5% slower code, than 5% faster code with occasional 1000% slow downs (in the worst case). Perhaps, but that's a strawman through & through. C++ exceptions don't have that performance cliff when thrown, per both the paper in the OP & in your link. They are fairly cheap to throw assuming a single-threaded application. That is, the fib example with 10% failure rate has the same performance using exceptions & using Boost::LEAF. Unless you're calling it "unfixable" because there isn't actually anything to fix in the first place...