4 ms·

There's a performance cost now because processor instruction sets have dropped hardware overflow detection due to disuse. Current processors are largely enginee

by zurn 11y ago

There's a performance cost now because processor instruction sets have dropped hardware overflow detection due to disuse. Current processors are largely engineered to just run legacy C code fast. See eg. https://news.ycombinator.com/item?id=7847980 https://news.ycombinator.com/item?id=7847980

johncolanduoni 11y ago
I think it is time for this removal to be reexamined, considering popular scripting languages like Python and Ruby (which check for overflows on all integer operations) face significant performance hits because of lack of hardware support for these instructions.
- zurn 11y ago
  The naive check-and-branch approach on current x86 only costs a couple of percent in integer-heavy and well tuned C code (see http://danluu.com/integer-overflow/ http://danluu.com/integer-overflow/). Integer operations in Python and Ruby are so glacially slow compared to C that the overflow checking overhead doesn't register at all due to all the other overhead there.
acqq 11y ago
No, overflow is still properly detected by common CPU instructions. There are flags that are set on overflow after the addition and subtraction and they can be tested. It's only hard to test the flags in "standard" C (I don't know if it's better with newer standards or those in progress) but the CPUs do their work on the hardware level.
- zurn 11y ago
  But like ploxiln said you now need a conditional branch to test for the overflow flag after the arithemetic operation, unlike the old overflow traps on x86/MIPS/Alpha etc.
  - acqq 11y ago
    I'm not aware that integer operations ever made traps on x86 and nobody actually uses floats for allocation sizes (in C). And checking the flag would be more than enough IF the languages supported it. It's the languages that should be changed to be able to simply check the overflow after the critical operations, not the CPUs. The overflow checks are needed only where something can "go wrong" not everywhere.

by zurn 11y ago

johncolanduoni 11y ago

I think it is time for this removal to be reexamined, considering popular scripting languages like Python and Ruby (which check for overflows on all integer operations) face significant performance hits because of lack of hardware support for these instructions.

zurn 11y ago
The naive check-and-branch approach on current x86 only costs a couple of percent in integer-heavy and well tuned C code (see http://danluu.com/integer-overflow/ http://danluu.com/integer-overflow/). Integer operations in Python and Ruby are so glacially slow compared to C that the overflow checking overhead doesn't register at all due to all the other overhead there.

acqq 11y ago

No, overflow is still properly detected by common CPU instructions. There are flags that are set on overflow after the addition and subtraction and they can be tested. It's only hard to test the flags in "standard" C (I don't know if it's better with newer standards or those in progress) but the CPUs do their work on the hardware level.

zurn 11y ago
But like ploxiln said you now need a conditional branch to test for the overflow flag after the arithemetic operation, unlike the old overflow traps on x86/MIPS/Alpha etc.
- acqq 11y ago
  I'm not aware that integer operations ever made traps on x86 and nobody actually uses floats for allocation sizes (in C). And checking the flag would be more than enough IF the languages supported it. It's the languages that should be changed to be able to simply check the overflow after the critical operations, not the CPUs. The overflow checks are needed only where something can "go wrong" not everywhere.