5 ms·

To add clarity to this explanation where I think it's needed: The llvm 'invoke' op is effectively a pseudo-op and does not necessarily indicate what a backend w

by cheez 10y ago

To add clarity to this explanation where I think it's needed: The llvm 'invoke' op is effectively a pseudo-op and does not necessarily indicate what a backend will do. It looks something like this (the exact details, I forget): llvm.invoke function-to-call, block-if-success, block-if-failure The backend translates this into: function-to-call block-if-success: .... Notice that there is no conditional. However, if in function-to-call, you have: throw exception() This will be translated into a table lookup that checks which exception handler is valid for the current block. This is the slow part and is generally no worse (theoretically) than frame-based exception handling.

openasocket 10y ago
How slow is slow? I don't have a good sense of scale for this. Are we talking hundreds of nanoseconds, or microseconds, or what?
- cheez 10y ago
  Theoretically, it's just as fast as frame-based exception handling which follows pointers up the stack. However, things that might impact the performance are things like code locality. For example, if the exceptional code hasn't been loaded into memory since it hasn't been needed, your program will need to stall while the code is loaded into memory. So basically, assume it is fast as hell (zero-cost) until you hit an exceptional case (so don't use exceptions for flow control.) In fact, I no longer use exceptions at all. I just "make a note and move on". Having objects that don't cause catastrophic failures when they are "null" is a good first step.
- rwallace 10y ago
  In my experience (desktop and server, haven't tried it on a microcontroller) exceptions have for all practical purposes zero cost until you actually throw one, at which point the cost is ten thousand clock cycles. That figure has stayed surprisingly constant over two decades of hardware and compilers for three different languages. (And, obviously, it's a negligible cost for an exceptional situation, but you wouldn't want to use it for flow control in a crunch-heavy inner loop.)
  - willvarfar 10y ago
    FWIW, the Symbian file server used an exception to get out of a crucial loop. It was a bit of laughable trivia, but a bunch of us set out to prove it was a bad idea... but on profiling it was provably noise. We moved from setjmp implementation to EABI zero-cost and it was still no issue. Just a data-point and a good case of profiling beating intuition :)

by cheez 10y ago

openasocket 10y ago

How slow is slow? I don't have a good sense of scale for this. Are we talking hundreds of nanoseconds, or microseconds, or what?

cheez 10y ago
Theoretically, it's just as fast as frame-based exception handling which follows pointers up the stack. However, things that might impact the performance are things like code locality. For example, if the exceptional code hasn't been loaded into memory since it hasn't been needed, your program will need to stall while the code is loaded into memory. So basically, assume it is fast as hell (zero-cost) until you hit an exceptional case (so don't use exceptions for flow control.) In fact, I no longer use exceptions at all. I just "make a note and move on". Having objects that don't cause catastrophic failures when they are "null" is a good first step.
rwallace 10y ago
In my experience (desktop and server, haven't tried it on a microcontroller) exceptions have for all practical purposes zero cost until you actually throw one, at which point the cost is ten thousand clock cycles. That figure has stayed surprisingly constant over two decades of hardware and compilers for three different languages. (And, obviously, it's a negligible cost for an exceptional situation, but you wouldn't want to use it for flow control in a crunch-heavy inner loop.)
- willvarfar 10y ago
  FWIW, the Symbian file server used an exception to get out of a crucial loop. It was a bit of laughable trivia, but a bunch of us set out to prove it was a bad idea... but on profiling it was provably noise. We moved from setjmp implementation to EABI zero-cost and it was still no issue. Just a data-point and a good case of profiling beating intuition :)