7 ms·

Yeah, though i'm not sure if exceptions really slow down compilation and in some compilers you can disable them anyway. Also you can redefine new to return null

by Crinus 7y ago

Yeah, though i'm not sure if exceptions really slow down compilation and in some compilers you can disable them anyway. Also you can redefine new to return null on failure, though if you are going to use new, delete, etc might as well bite the bullet and use the entire language anyway (and instead of redefining new, use a template that does the allocation and initialization based on some common convention and a macro that causes an error whenever new is used since you can ensure no exceptions will be thrown... at least from new - but IMO a better way is to just stick with C and avoid the tarpit that is C++).

klingonopera 7y ago
...my compile times rarely take more than a minute, so I can't really relate to that, but exceptions will slow down execution and add an overhead to the binary's file-size.
- wvenable 7y ago
  Exceptions don't generally slow down execution -- they usually have zero runtime cost if they're not thrown making them better than error returns for performance. However, the exchange is, as you said, that they do add a lot of overhead to the file-size.
  - klingonopera 7y ago
    Regarding error handling, I agree with this author[0], and find the C-based approach much better than C++'s try/throw/catch methods. Regarding execution times, I don't know from first-hand experience, I did some research and found this[1]. The third sentence in that reply ("The error code is not sensitive to the percentage of occurrence") is AFAIK wrong (because of speculative execution, I believe?), but the rest seems quite solid. [0]: http://250bpm.com/blog:4 http://250bpm.com/blog:4 [1]: https://stackoverflow.com/a/52513707 https://stackoverflow.com/a/52513707
  - vardump 7y ago
    Something that generates extra code that ends up in the instruction cache during execution is not zero cost. There's cost to transfer it through memory and cache hierarchies and there's cost when it causes the CPU to drop some other L1C cache line.
    - gpderetta 7y ago
      Well, if the exception is not thrown, no code related to the exceptional path goes into the instruction cache (not even checking for exception propagation). Assuming of course a non-completely dumb compiler that puts exceptional path code and unwinds tables in separate pages than hot code.
      - vardump 7y ago
        True. I think I'll test whether use of exceptions can affect optimizations concerning register allocation and spilling, like function prologues and epilogues. Unwinding will also need to call destructors, and for that you'll need to have the object pointer somewhere in (stack frame) memory. But it might be in just a register. Unless, of course, the unwinding engine can look into registers as well. I guess it's not a huge deal either way, especially in 32-bit x86 code. For large register file systems it might be a different story, forcing otherwise unnecessary spills. Regardless, I'll find out when I got some time. Anyways, my point was more generic. So-called zero-cost abstractions are my pet peeve, because they're often not zero cost precisely because of larger generated code size. Typical microbenchmarks don't capture this, because their hot path can usually fit comfortably in L1 code and data caches.
        gpderetta 7y ago
        In theory the optimizer can optimize exactly as if the exceptions where not there, in practice some code motion optimizations might be restricted across exception boundaries simply because it might be too much work to make it work correctly. So it is possible on some tests cases to measure a difference. Regarding spilling and register allocation, IIRC[1] the unwind tables contain a simple bytecode that is interpreted by the undwinder to fixup stack and restore registers (indexed by the current ip address), so no actual registration of object to destroy need to be done, nor does the frame pointer need to exist at all: the unwinder interprets the bytecode to recursively adjust each stack frame and registers to the expected values. [1] At some point I had actually learned to write unwind tables by hand, of course I completely forgot everything about that: look at trampoline_thunk at https://github.com/gpderetta/delimited/blob/master/delimited.hpp#L114 https://github.com/gpderetta/delimited/blob/master/delimited... even with extensive comments is still write-only code. It doesn't help that there aren't a lot of DWARF CFI tutorials around.
- Crinus 7y ago
  Heh, this reminds me of the Abrash quote about optimization mentioned a few days ago (from his black book): > We're so used to slow software that when a compile-and-link sequence that took two minutes on a PC takes just ten seconds on a 486 computer, we're ecstatic—when in truth we should be settling for nothing less than instantaneous response. (from https://github.com/jagregory/abrash-black-book/blob/master/src/chapter-01.md https://github.com/jagregory/abrash-black-book/blob/master/s...) Personally i'm annoyed when my compile times take more than a few seconds :-P

by Crinus 7y ago

klingonopera 7y ago

...my compile times rarely take more than a minute, so I can't really relate to that, but exceptions will slow down execution and add an overhead to the binary's file-size.

wvenable 7y ago
Exceptions don't generally slow down execution -- they usually have zero runtime cost if they're not thrown making them better than error returns for performance. However, the exchange is, as you said, that they do add a lot of overhead to the file-size.
- klingonopera 7y ago
  Regarding error handling, I agree with this author[0], and find the C-based approach much better than C++'s try/throw/catch methods. Regarding execution times, I don't know from first-hand experience, I did some research and found this[1]. The third sentence in that reply ("The error code is not sensitive to the percentage of occurrence") is AFAIK wrong (because of speculative execution, I believe?), but the rest seems quite solid. [0]: http://250bpm.com/blog:4 http://250bpm.com/blog:4 [1]: https://stackoverflow.com/a/52513707 https://stackoverflow.com/a/52513707
- vardump 7y ago
  Something that generates extra code that ends up in the instruction cache during execution is not zero cost. There's cost to transfer it through memory and cache hierarchies and there's cost when it causes the CPU to drop some other L1C cache line.
  - gpderetta 7y ago
    Well, if the exception is not thrown, no code related to the exceptional path goes into the instruction cache (not even checking for exception propagation). Assuming of course a non-completely dumb compiler that puts exceptional path code and unwinds tables in separate pages than hot code.
    - vardump 7y ago
      True. I think I'll test whether use of exceptions can affect optimizations concerning register allocation and spilling, like function prologues and epilogues. Unwinding will also need to call destructors, and for that you'll need to have the object pointer somewhere in (stack frame) memory. But it might be in just a register. Unless, of course, the unwinding engine can look into registers as well. I guess it's not a huge deal either way, especially in 32-bit x86 code. For large register file systems it might be a different story, forcing otherwise unnecessary spills. Regardless, I'll find out when I got some time. Anyways, my point was more generic. So-called zero-cost abstractions are my pet peeve, because they're often not zero cost precisely because of larger generated code size. Typical microbenchmarks don't capture this, because their hot path can usually fit comfortably in L1 code and data caches.
      - gpderetta 7y ago
        In theory the optimizer can optimize exactly as if the exceptions where not there, in practice some code motion optimizations might be restricted across exception boundaries simply because it might be too much work to make it work correctly. So it is possible on some tests cases to measure a difference. Regarding spilling and register allocation, IIRC[1] the unwind tables contain a simple bytecode that is interpreted by the undwinder to fixup stack and restore registers (indexed by the current ip address), so no actual registration of object to destroy need to be done, nor does the frame pointer need to exist at all: the unwinder interprets the bytecode to recursively adjust each stack frame and registers to the expected values. [1] At some point I had actually learned to write unwind tables by hand, of course I completely forgot everything about that: look at trampoline_thunk at https://github.com/gpderetta/delimited/blob/master/delimited.hpp#L114 https://github.com/gpderetta/delimited/blob/master/delimited... even with extensive comments is still write-only code. It doesn't help that there aren't a lot of DWARF CFI tutorials around.
Crinus 7y ago
Heh, this reminds me of the Abrash quote about optimization mentioned a few days ago (from his black book): > We're so used to slow software that when a compile-and-link sequence that took two minutes on a PC takes just ten seconds on a 486 computer, we're ecstatic—when in truth we should be settling for nothing less than instantaneous response. (from https://github.com/jagregory/abrash-black-book/blob/master/src/chapter-01.md https://github.com/jagregory/abrash-black-book/blob/master/s...) Personally i'm annoyed when my compile times take more than a few seconds :-P