3 ms·

> Somehow, it ends up with the same performance despite all of this constant branching error-checking and better performance when re-throwing exceptions. SJLJ

> Somehow, it ends up with the same performance despite all of this constant branching error-checking and better performance when re-throwing exceptions. SJLJ exceptions were also deterministic and slow. The author's recorded a 2-4% slowdown in the case that exceptions weren't thrown (relative to zero-cost DWARF EH), and a 1-2% slowdown in the case that exceptions were thrown (again, relative to DWARF EH). That's not an improvement, that's a regression.

gumby 7y ago
Real-time != fast.
aw1621107 7y ago
For "standard" applications, sure, but the paper mentions that for embedded uses code size and determinism can be more important than pure execution speed, and perhaps a few percent slowdown would be considered acceptable for embedded development if it allows the use of exceptions.
Joker_vD 7y ago
Perhaps. But a) apparently branch prediction is good enough to make all this constant checking for exceptional returns to slow down the execution by only a couple of percents; b) apparently exception propagation and re-throwing is way, way faster than in the standard implementation; c) the exclusion of the unwind tables makes the code 3 times smaller on ARM, and 5 times smaller on x86-64. That's pretty huge. So all in all, I'd say that if those figures actually hold, then this approach is pretty solid. It's just surprising, given how much complaining there is about how Go's idiom of "if err != nil { return nil, err }", or Rust's "let v = some_fun()?" kills performance because of branch mis-prediction and hot path code bloat, so maybe those figures don't actually hold?
- aw1621107 7y ago
  > given how much complaining there is about how Go's idiom of "if err != nil { return nil, err }", or Rust's "let v = some_fun()?" kills performance because of branch mis-prediction and hot path code bloat Was that the main complaint? I thought that Go's thing was was more about being noisy boilerplate and a bug magnet rather than a performance issue. Not sure about Rust, either, since IIRC the ? operator is sugar for the try! macro, which itself was just sugar for bubbling up a Result<Err>.

gumby 7y ago

Real-time != fast.

aw1621107 7y ago

For "standard" applications, sure, but the paper mentions that for embedded uses code size and determinism can be more important than pure execution speed, and perhaps a few percent slowdown would be considered acceptable for embedded development if it allows the use of exceptions.

Joker_vD 7y ago

Perhaps. But a) apparently branch prediction is good enough to make all this constant checking for exceptional returns to slow down the execution by only a couple of percents; b) apparently exception propagation and re-throwing is way, way faster than in the standard implementation; c) the exclusion of the unwind tables makes the code 3 times smaller on ARM, and 5 times smaller on x86-64. That's pretty huge. So all in all, I'd say that if those figures actually hold, then this approach is pretty solid. It's just surprising, given how much complaining there is about how Go's idiom of "if err != nil { return nil, err }", or Rust's "let v = some_fun()?" kills performance because of branch mis-prediction and hot path code bloat, so maybe those figures don't actually hold?

aw1621107 7y ago
> given how much complaining there is about how Go's idiom of "if err != nil { return nil, err }", or Rust's "let v = some_fun()?" kills performance because of branch mis-prediction and hot path code bloat Was that the main complaint? I thought that Go's thing was was more about being noisy boilerplate and a bug magnet rather than a performance issue. Not sure about Rust, either, since IIRC the ? operator is sugar for the try! macro, which itself was just sugar for bubbling up a Result<Err>.