5 ms·

I am curious where you get 10-20%. Dan luu measures <1% at https://danluu.com/integer-overflow/ https://danluu.com/integer-overflow/

howinteresting 4y ago
Those are figures I've heard second hand on a real project from some people I trust. My understanding is that a lot of optimizations become more complicated that way. I could be wrong though.
throwaway81523 4y ago
1) it looks a lot worse than 1%, 2) it is on x86 not risc-v, 3) code bloat. Meanwhile risc-v and everything else checks overflow for floating point arithmetic because it is mandated by the IEEE standard. That doesn't seem to cause slowdowns. There is a code sequence in the risc-v docs someplace for doing a checked integer addition and it takes 3 or 4 instructions in the general case. Blecch. Better to set a flag like the FPU does, and check it at the end of a basic block.
- zozbot234 4y ago
  That's only the suggested overflow checking for a single operation. When you have multiple add/sub/mul/compare operations in a row, checking for actual overflow becomes quite non-trivial and is not something that can be done by the hardware. Floating point has no equivalent to this, which is why it makes sense to have overflow checking as part of the instruction.
  - throwaway81523 4y ago
    I don't understand what you are saying. An overflow in an intermediate result should signal an overflow unless you're relying on some special property of 2's complement arithmetic in which case you should be using specific datatypes to suppress the check. All I'm saying about floating point is that the presence of overflow checking in high performance FPU's falsifies (afaict) the claim that it's unfeasible to do the same thing for integers.
    - andrekandre 4y ago
      > FPU's falsifies (afaict) the claim that it's unfeasible to do the same thing for integers. was the argument that its unfeasible or that just not doing it is a net win?
- renox 4y ago
  Even better to have a 'trap on integer overflow' state (either a bit in each instruction or in a context register), this way there's no/less icache impact.
- adwn 4y ago
  > 1) it looks a lot worse than 1% The 9% / 28% are for -fsanitize=signed-integer-overflow,unsigned-integer-overflow, which prints a warning on overflow. The version with -fsanitize-undefined-trap-on-error, which aborts the process, only causes a slowdown of 0-1%.

howinteresting 4y ago

Those are figures I've heard second hand on a real project from some people I trust. My understanding is that a lot of optimizations become more complicated that way. I could be wrong though.

throwaway81523 4y ago

1) it looks a lot worse than 1%, 2) it is on x86 not risc-v, 3) code bloat. Meanwhile risc-v and everything else checks overflow for floating point arithmetic because it is mandated by the IEEE standard. That doesn't seem to cause slowdowns. There is a code sequence in the risc-v docs someplace for doing a checked integer addition and it takes 3 or 4 instructions in the general case. Blecch. Better to set a flag like the FPU does, and check it at the end of a basic block.

zozbot234 4y ago
That's only the suggested overflow checking for a single operation. When you have multiple add/sub/mul/compare operations in a row, checking for actual overflow becomes quite non-trivial and is not something that can be done by the hardware. Floating point has no equivalent to this, which is why it makes sense to have overflow checking as part of the instruction.
- throwaway81523 4y ago
  I don't understand what you are saying. An overflow in an intermediate result should signal an overflow unless you're relying on some special property of 2's complement arithmetic in which case you should be using specific datatypes to suppress the check. All I'm saying about floating point is that the presence of overflow checking in high performance FPU's falsifies (afaict) the claim that it's unfeasible to do the same thing for integers.
  - andrekandre 4y ago
    > FPU's falsifies (afaict) the claim that it's unfeasible to do the same thing for integers. was the argument that its unfeasible or that just not doing it is a net win?
renox 4y ago
Even better to have a 'trap on integer overflow' state (either a bit in each instruction or in a context register), this way there's no/less icache impact.
adwn 4y ago
> 1) it looks a lot worse than 1% The 9% / 28% are for -fsanitize=signed-integer-overflow,unsigned-integer-overflow, which prints a warning on overflow. The version with -fsanitize-undefined-trap-on-error, which aborts the process, only causes a slowdown of 0-1%.