Integer Overflow Checking Cost
danluu.com
Integer Overflow Checking Cost
1–10 of 17 posts
Re: Integer Overflow Checking Cost
#22014 (probably? Or 2008. Old and no date) Previously (166 points, 2014, 107 comments) https://news.ycombinator.com/item?id=8765714
Re: Integer Overflow Checking Cost
#32014 (probably? Or 2008. Old and no date) Previously (166 points, 2014, 107 comments) https://news.ycombinator.com/item?id=8765714
Resubmitting it seems timely, given recent Linux kernel news (e.g. https://lwn.net/Articles/1065889/).
Re: Integer Overflow Checking Cost
#4[flagged]
Re: Integer Overflow Checking Cost
#52014 (probably? Or 2008. Old and no date) Previously (166 points, 2014, 107 comments) https://news.ycombinator.com/item?id=8765714
The archive says "12/14", so 2014 seems about right.
Re: Integer Overflow Checking Cost
#6In 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).
Re: Integer Overflow Checking Cost
#7Definitely cheaper than using Electron I would say
Re: Integer Overflow Checking Cost
#8In 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).
> 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-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".
Re: Integer Overflow Checking Cost
#9In 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).
Code 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.
Re: Integer Overflow Checking Cost
#10In 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).
Code 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.
One example of such an optimization is that overflow checking can prevent vectorization of code.
See for example this post: https://lemire.me/blog/2016/12/06/dont-assume-that-safety-co.... It is ancient, but I don’t see a reason why it would have become outdated.