5 ms·
Integer Overflow Checking Cost
- gnabgib 5mo ago2014 (probably? Or 2008. Old and no date) Previously (166 points, 2014, 107 comments) https://news.ycombinator.com/item?id=8765714 https://news.ycombinator.com/item?id=8765714
- zahlman 5mo agoResubmitting it seems timely, given recent Linux kernel news (e.g. https://lwn.net/Articles/1065889/ https://lwn.net/Articles/1065889/).
- aw1621107 5mo agoThe archive says "12/14", so 2014 seems about right.
- pseudohadamard 5mo agoIt's gcc 4.x so more an archaeological curiosity than anything else. Did gcc have stdckdint back then?
- tcfhgj 5mo agoDefinitely cheaper than using Electron I would say
- ardline 5mo ago[flagged]
- mayoff 5mo agoIn Swift (Apple’s C++ successor), the normal operators (`+`, `-`, `*`) trap on overflow for integer types. If you want twos complement wrapping, you can use `&+`, `&-`, and `&*`. Given that Apple has been making its own CPU cores for years now, I suspect overflowing checking on Apple CPUs is virtually free (aside from code size).
- qayxc 5mo ago> Given that Apple has been making its own CPU cores for years now, I suspect overflowing checking on Apple CPUs is virtually free (aside from code size). Never make guesses based on a particular programming language. In Apple's own C documentation (https://developer.apple.com/documentation/xcode/integer-overflow https://developer.apple.com/documentation/xcode/integer-over...) it is stated that "Overflows result in undefined behavior." and enabling wrapping behaviour "may adversely impact performance", indicating that overflow detection is in fact not "virtually free".
- debugnik 5mo ago"Enabling wrapping behaviour" for signed integers disallows a lot of optimizations based on signed overflow being undefined behaviour, which is a matter of language and compiler design. This says nothing about the cost of checked arithmetic itself on the CPU.
- qayxc 5mo agoIt does, though. UB and associated optimisations wouldn't be an issue if defined behaviour would not have an impact on performance. If the cost would be zero or negligible, the compiler wouldn't need to care and hence warnings like this wouldn't need to be explicitly stated.
- debugnik 5mo agoAnd yet Swift doesn't rely on these optimizations, preferring to trap instead. Again, the guess above was about the CPU and we're conflating language-specific UB optimisations.
- saagarjha 5mo agoCode size (and branch table entries) are not free, of course. The other thing to note is that trapping operators often need to trap precisely which can lead to missed optimizations.