3 ms·

Well again -- I don't know how Rust does it specifically, but when you compile C++ programs in g++ with exceptions disabled you pretty consistently see a 10% sp

by maxk42 7y ago

Well again -- I don't know how Rust does it specifically, but when you compile C++ programs in g++ with exceptions disabled you pretty consistently see a 10% speed improvement right off the bat and the performance falls more closely in line with the performance of C code. Specifics aside the broader point is that the runtimes between the two languages will differ.

paulddraper 7y ago
Huh, that surprises me. g++ exceptions have been touted as zero-cost for the happy path. https://stackoverflow.com/a/13836329 https://stackoverflow.com/a/13836329 http://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012-Skochinsky-Compiler-Internals.pdf http://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012...
- jcranmer 7y ago
  Zero-cost exception handling is only so cheap by excluding a lot of things from the cost/benefit analysis. It adds no extra code to the exception-free path. But it has a few major impacts: * Exception tables are not particularly small, and can involve extra relocations, which can increase the time it takes to load the binary. * Every function call where there is a variable with a destructor in scope has an implicit try/catch wrapped around it. This can increase code size tremendously, which hits your instruction cache. And, unlike the unwind tables, the relevant data is in the middle of your code sections, so you can't do tricks like lazy loading of the data. * Every time you call a function that may throw, you need to break up the basic blocks. So every optimization in the compiler that cannot work across basic block boundaries is going to perform much more poorly with ZCEH. * Of the various kinds of basic block edges, the exceptional edges are the hardest to reason about (computed goto edges being the second hardest). So many optimizations that can work across basic blocks are still going to bail out in ZCEH conditions. * It's possible to ameliorate the optimization costs if the compiler can figure out that the callee isn't going to throw an exception and turn a may-throw call into a may-not-throw call. But memory allocation may throw (by default), so anything that might allocate memory (say, adding a value to a std::vector) potentially throws an exception and inhibits optimization.

by maxk42 7y ago

paulddraper 7y ago

Huh, that surprises me. g++ exceptions have been touted as zero-cost for the happy path. https://stackoverflow.com/a/13836329 https://stackoverflow.com/a/13836329 http://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012-Skochinsky-Compiler-Internals.pdf http://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012...

jcranmer 7y ago
Zero-cost exception handling is only so cheap by excluding a lot of things from the cost/benefit analysis. It adds no extra code to the exception-free path. But it has a few major impacts: * Exception tables are not particularly small, and can involve extra relocations, which can increase the time it takes to load the binary. * Every function call where there is a variable with a destructor in scope has an implicit try/catch wrapped around it. This can increase code size tremendously, which hits your instruction cache. And, unlike the unwind tables, the relevant data is in the middle of your code sections, so you can't do tricks like lazy loading of the data. * Every time you call a function that may throw, you need to break up the basic blocks. So every optimization in the compiler that cannot work across basic block boundaries is going to perform much more poorly with ZCEH. * Of the various kinds of basic block edges, the exceptional edges are the hardest to reason about (computed goto edges being the second hardest). So many optimizations that can work across basic blocks are still going to bail out in ZCEH conditions. * It's possible to ameliorate the optimization costs if the compiler can figure out that the callee isn't going to throw an exception and turn a may-throw call into a may-not-throw call. But memory allocation may throw (by default), so anything that might allocate memory (say, adding a value to a std::vector) potentially throws an exception and inhibits optimization.