3 ms·

Why would error-handling code impact performance? Besides, exceptions in C++ are known to have negative impacts on overall performance even if you don't use th

by bogwog 4y ago

Why would error-handling code impact performance? Besides, exceptions in C++ are known to have negative impacts on overall performance even if you don't use them. (see: https://preshing.com/20110807/the-cost-of-enabling-exception-handling/ https://preshing.com/20110807/the-cost-of-enabling-exception...)

int_19h 4y ago
This blog post is specifically talking about 32-bit x86 C++ ABI, which was notoriously not zero-cost wrt exceptions even on success-only code paths. Lessons learned from that went into the Itanium C++ exceptions ABI based on static unwind maps, which has been adopted by basically every other architecture except for Windows, which has its own take (that is still zero-cost).
- vlovich123 4y ago
  Huh? It’s for skylake which works imply x64 no? I doubt Daniel Lenore is running 32 but code given his background of focusing on applying AVX everywhere which requires x64. X64 uses itanium exception handling.
  - Kranar 4y ago
    OP was ambiguous, he means that the article "The Cost of Enabling Exception Handling" that was linked only applies to Windows x86, not to Windows AMD64 or the Itanium ABI. The Itanium ABI and 64-bit Windows have near-zero cost when exceptions aren't thrown.
junon 4y ago
Code paging. If your hot code spans multiple pages, you run the risk of the CPU needing to perform page fetching to continue executing your code. If your exception handling code causes the hot path to exceed the page size, then you run the risk of cache misses which can cripple performance. Rust has the #[cold] attribute for this exact reason - to mark functions or branches as 'cold', placing them into a separate section to reduce the hot path's code size.
vgatherps 4y ago
If you use error codes, you always pay the cost (even cheap) of generating codes. If the function isn’t online able this might increase the stack usage, prevent inlining in the first place, etc. With exceptions the error paths don’t even have to exist in your hot code. The cost of exceptions when they aren’t thrown has come a long way since 2011 (the time of that post) in clang and gcc and I’m 99% sure is almost always zero now.

by bogwog 4y ago

int_19h 4y ago

This blog post is specifically talking about 32-bit x86 C++ ABI, which was notoriously not zero-cost wrt exceptions even on success-only code paths. Lessons learned from that went into the Itanium C++ exceptions ABI based on static unwind maps, which has been adopted by basically every other architecture except for Windows, which has its own take (that is still zero-cost).

vlovich123 4y ago
Huh? It’s for skylake which works imply x64 no? I doubt Daniel Lenore is running 32 but code given his background of focusing on applying AVX everywhere which requires x64. X64 uses itanium exception handling.
- Kranar 4y ago
  OP was ambiguous, he means that the article "The Cost of Enabling Exception Handling" that was linked only applies to Windows x86, not to Windows AMD64 or the Itanium ABI. The Itanium ABI and 64-bit Windows have near-zero cost when exceptions aren't thrown.

junon 4y ago

Code paging. If your hot code spans multiple pages, you run the risk of the CPU needing to perform page fetching to continue executing your code. If your exception handling code causes the hot path to exceed the page size, then you run the risk of cache misses which can cripple performance. Rust has the #[cold] attribute for this exact reason - to mark functions or branches as 'cold', placing them into a separate section to reduce the hot path's code size.

vgatherps 4y ago

If you use error codes, you always pay the cost (even cheap) of generating codes. If the function isn’t online able this might increase the stack usage, prevent inlining in the first place, etc. With exceptions the error paths don’t even have to exist in your hot code. The cost of exceptions when they aren’t thrown has come a long way since 2011 (the time of that post) in clang and gcc and I’m 99% sure is almost always zero now.