In 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".
"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.
It 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.
And 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.
It is best to have ergonomic checked version of arithmetic functions and always use them when possible, and use the debug only checked versions on other places.
Performance of checked arithmetic will basically never matter around things like allocation in my experience
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.
Vector instructions usually don't have overflow flags, so a compiler can't easily vectorize loops containing overflow checks. However, detecting overflows in integer operations requires only a bit of bitwise arithmetic. In my experiments, this lead to an overhead of only 7% for vectorized additions with overflow checks: https://cedardb.com/blog/vectorized_overflows/
That's with a simple data operation and using a recent x86 vector ISA (AVX-512) that is only available on some systems, notably excluding any current Intel desktop CPU.
The real killer isn't the data operations, though, it's if the overflow checks interfere with converting the loop logic or data addressing to vectorizable form. Indexing with 32-bit signed int vs. unsigned int on a 64-bit platform in C is a classic case -- with unsigned the compiler cannot assume that addressing offsets don't wrap, which then prevents coalescing data accesses into vector loads and stores.
The second sentence of your summary is fine, but I don’t like the first sentence:
> Use your language’s type system to parse unstructured inputs.
We don’t use the type system to parse. We use the type system to provide evidence (also called a proof or a witness) that parsing was successful, and we rely on the language’s access control facilities (public/private) and the soundness of its type system to prevent fabrication of false evidence.
Quaternary search effectively performs both of the next loop iteration’s possible comparisons simultaneously with the current iteration’s comparison. This is a little more complex than simple loop unrolling.
Regardless, both kinds of search are O(log N) with different constants. The constants don’t matter so much in algorithms class but in the real world they can matter a lot.
While plenty about the iPad situation sucks, my biggest gripe is the discontinuation of the Smart Keyboard Folio. This was the one that only had a keyboard, no trackpad, but could fold all the way back, which the Magic Keyboard (with trackpad) cannot. The Smart Keyboard Folio was just the perfect form factor: there when you need it, discretely out of the way when you didn’t. And when you were using it, the iPad was perfectly balanced to sit on your lap even in cramped circumstances, which the Magic Keyboard is most definitely not.
Sure, get rid of the Magic Keyboard with its unnecessary trackpad. But bring back the Smart Keyboard Folio. It was a delight.
It's kind of crazy that the IRS (among other United States government agencies) uses ID.me for account management. The .me domain belongs to Montenegro.
I think ID.me is a private company. So yeah, it’s especially fucking stupid that they use that in the first place. Any gov login should be required to go through a .gov tld. At least reverse proxy it or something!
When my daughter finally needed one of those godawful monopoly-priced calculators for school, we went to the nearest pawn shop and found a TI 84 Plus, opened, for $40, and a TI 84 Plus CE in its unopened (but roughed up) original packaging for $65.
Somehow Woot still has a supply of the Smart Keyboard Folio for certain 11" iPads Pro/Air.
My wife is still using an older gen 11" iPad Pro and her keyboard folio stopped working (they fall apart after a few years ), so I took a gamble and ordered one. It arrived in the original, sealed packaging. As far as I can tell, it had never been opened, and it is perfect condition and works great. My wife is very happy. I bought a second one for when this one falls apart.
Most of the “delivery” (getting it from the factory to its final installed location) was done by machine: forklifts, cranes, ships, trucks, and (I'm guessing) a motorized lift on the back of the delivery truck.
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).
reply