Exceptions make your code faster in the non-exceptional case.
See all those if-branches for error checks that don't exist in your code? That branch-free code is going to run faster than your branchy code. And the code's shorter, because it doesn't have the checks and handling intermixed, which makes it fit better into cache.
This isn't rocket science, I'm amazed that this isn't obvious.
Ever since the 486 we've had zero-cost instructions, for example.
More pertinent to this, modern CPUs have multi-stage pipelines and branch prediction.
Third, just the possibility of throwing an exception has a cost as the program has to have the code to unwind the stack.
Last, humans have become increasingly bad at second-guessing compiler optimizations.
> This isn't rocket science, I'm amazed that this isn't obvious.
Thing is, it kind of is rocket science. And it's not obvious. That's why you have to test.
Now you could take the position that exception lead to better designed code and might have other such benefits. Personally, I've become more convinced over the years that exceptions are a false economy.
A correctly predicted branch is still slower than no branch. An incorrectly predicted branch is one of the slowest things you can have happen on a modern CPU.
> Third, just the possibility of throwing an exception has a cost as the program has to have the code to unwind the stack.
Incorrect. The exception handling code does not execute in the normal path.
-fno-exceptions ~never makes your code faster. It does, however, shrink your binary size. Which is a non-trivial cost, but not the focus of the discussion.
Per Agner Fog, misprediction on Ryzen will cost you 18 cycles. On Haswell family, 15 to 20. Floating point division can cost you more cycles, both in latency and throughput. Even just plain old L3 latency can be worse than misprediction.
No, on Ryzen, 32-bit float division, divps instruction, has latency 10 cycles, throughput 3 cycles. 64-bit float division, divpd instruction, has latency up to 13, throughput up to 5. Both faster than a cache miss, in latency and especially throughput.
> Even just plain old L3 latency can be worse than misprediction.
Yes. BTW, the slowest thing that can happen on modern CPU is not L3 access, it’s access to a cache line modified by another CPU core. Even slower than main memory latency.
true but the instruction fetcher is driven by the branch predictor, so a misprediction to rarely executed code in practice also implies a cache miss.
This is true only if only exceptional things throw exceptions. In some APIs normal, but not successful things throw exceptions. Things like file not found are often pretty normal, but may throw an exception.
Exceptions are exactly same as errors, they're just a different way to handle them. Errors are natural to programming, because nearly every function may end up in two states: it successfully carried out the task (no error) or it failed to carry it out and here's the reason why (error).
The reason we have exceptions instead of errors is generally because we want the code to look syntactically sweet. A mere "a.b + c.d" in modern language may involve three method calls: to get "a.b", to get "c.d", and to add them using some custom definition of "+". Each of these methods may run into an error and exceptions provide a syntactically sweet way to handle this.
It's quite rare to want to handle an error condition half-way up the stack and do anything more than log / cleanup and resume unwinding (whether implicitly via exceptions or monadic errors or automatically via exception unwinding library).
You normally handle errors like file not found, couldn't connect, etc. near the leaf call which failed, if you want to handle them at all. So it makes sense to decide what error condition you want; do you abort the whole task (exception works great!), or do you do something interesting like retries or alternatives (exceptions not so hot, booleans or some kind of error code better reflects that the handler code is conditional rather than exceptional).
It may not be possible to make exceptions totally free, but the rest of the language may be slow enough so they won't stick out :) Example: Python.
There certainly are APIs that abuse exceptions, but IMHO far fewer than most Go (et al) programmers claim.
The unwind info might end up calling destructors or exception handlers, which might or might not be on a separate page. You are probably referring to that.
> Incorrect. The exception handling code does not execute in the normal path.
But it does need to undo all allocations and such that were made between the exception and the nearest exception handler, doesn't it? Isn't this "unwinding the stack"?
But what you're referring to is a cost, yes, but only a cost when an exception happens which should be rare. And it's not that much more expensive of an unwind than what would happen if you `if (err = thing()) { return err; }` everywhere in your call stack anyway.
it should do so if you use error codes too - else you've got an incorrect program which leaks things like memory (not too bad on our current computers), file handles (really sucks on windows), sockets (really sucks on linux).
On the other hand unwinding the stack is not complex and won't add much to program size.
The demo benchmark, for example, would produce basically always missed branches. Well, if would if the compiler didn't just strip the empty branch, invalidating the entire benchmark.
Branch predictors steadily get better, sure, but they're not infallible. Remember that reducing the total number of branches in a program helps the branch predictor predict better.
For performance-sensitive code, I've yet to find a real-world case where exceptions out-perform exception-free code. Nor have I seen much in the way of contrary evidence among people that care about performance.
Otherwise, there are too many differences in detail to generalize. Rust can take advantage of reduced aliasing that C++ can't, but the compiler doesn't because that code is still too buggy to turn on.
Last time I compared carefully, Rust and C++ built with Clang had identical performance, to well under 1%: much smaller than, e.g., the difference between Clang and Gcc.
So, while the successfully predicted branches are pretty cheap, many fewer can be predicted. Synthetic benchmarks generally have many fewer branches to predict than live code has.
You can optimize the code generation around that knowledge but not passing it directly to the CPU
All major AMD and Intel processors do static branch prediction.