[llvm-dev] Exceptions and performance
David Chisnall via llvm-dev
llvm-dev at lists.llvm.org
Fri Aug 14 07:55:04 PDT 2020
On 14/08/2020 03:39, David Blaikie via llvm-dev wrote:
> Once you get past the nothrow default problems, then you probably have
> to deal with the performance tradeoffs between the current strategy
> for exception implementations (table based, etc) compared to the
> tradeoffs for explicit error handling. You'd probably find that using
> exceptions for/every/ error return would not be the right perf
> tradeoff for many use cases where errors are at least somewhat common.
> So you'd probably end up with a hybrid solution - some things using
> exceptions where the failure is rare/going to be costly anyway
> (stopping the process, showing an error to a user/asking for user
> input about retrying, etc) and then still using explicit error
> handling for other things.
There's a second-order effect here too. Everyone knows exceptions are
slow, so everyone writes fast-path code with explicit error returns. As
a result, modern branch predictors are *really* good at predicting the
no-error case. A lot of the arguments about checked return values being
slow date back to in-order processors where adding any instructions on
the fast path was always a slowdown, even if they were not-taken branches.
I did some experiments about a year ago with different hand-written
assembly implementations of error handling control flow patterns and it
was really hard to beat the checked return on recent Intel hardware.
This was a microbenchmark, so didn't see effects from increased cache usage.
There's also the fact that explicit error checking lets the programmer
simplify the CFG explicitly. If you're calling two functions that don't
depend on any data flow between them, you can do something like:
auto a = someFn();
auto b = someOtherFn();
if (!a || !b)
doSomeErrorHandlingStuffs();
Transforming exception-driven code into this structure would be an
invalid transform unless the compiler could prove that someOtherFn() has
no observable side effects.
David
More information about the llvm-dev
mailing list