Don’t assume that safety comes for free: a Swift case study

This seems totally misguided and inflammatory. The points made boil down to:<p>1. Overflow checking adds about a 2x overhead to &quot;+&quot; in a loop<p>2. Using &quot;reduce&quot; rather than a loop also has ~2x overhead<p>Neither is really surprising, and hardly seems to warrant the final tangent that &quot;I do not think it is universally a good thing that software should crash when an overflow occurs&quot; since &quot;a mission-critical application could crash because an unimportant function in a secondary routine overflows&quot;.<p>What about the mission-critical bugs, especially security bugs, that are <i>caused by</i> overflows?<p>Swift&#x27;s default behavior, of aggressively checking for overflows, is at least arguable, and there&#x27;s a school of thought in software engineering that says &quot;don&#x27;t nail your code to the wall&quot;, i.e. don&#x27;t try to keep it running at all costs when something goes wrong. Let it crash and restart it. Obviously that approach works well in some scenarios and less well in others. The creators of Swift reckon it&#x27;s a good default for most programmers and I reckon they&#x27;re onto something.<p>The fact that the overhead is <i>only</i> 2x for a tight inner loop should be a cause for celebration, not dire warnings. And as the author himself shows, it&#x27;s very easy to disable overflow checking on a per-operation basis when you want to.

Most costly software bug I&#x27;ve ever witnessed was caused by an integer overflow. Thankfully, it wasn&#x27;t <i>caused</i> by me, but if I had been auditing the code, I probably wouldn&#x27;t have found the bug.<p>The system was billing customers credit cards depending on how long they had used the service. Time was measured in milliseconds (uh-oh!) for no apparent reason. Usage could have been measured in seconds or even days but someone thought it was good to be extra precise. And System.currentTimeMillis() returns milliseconds.<p>The default charging period was 14 days which worked well. So the maximum number of milliseconds that could be charged (for someone who used the system the whole month) was 1,209,600,000. Then the company decided to change the period to every two months (60 days) instead to save money as there was a fixed cost added to every credit card transfer.<p>Guess what 60 * 24 * 3600 * 1000 is? It&#x27;s a number a bit bigger than 2^31 - 1 which is the most positive primitive integer value in Java. And the &quot;totalDuration&quot; variable had type &quot;int&quot;. :)<p>So totalDuration wrapped around which caused the system to retry the transaction over and over and debit customers hundreds of times more than what they really owed. The resulting fallout from that debacle was one of the reasons the company went bankrupt. Integer overflow checking could have saved them.

Now that more languages are checking for integer overflow, it&#x27;s time for integer overflow exceptions to re-appear in hardware. DEC VAX machines had this, but C didn&#x27;t use them. With the hardware doing the checking in parallel, there&#x27;s no performance penalty.<p>If you want wrap-around arithmetic (which is rare) you should have to write something like<p><pre><code> unsigned short i,j; i = (i + j) % 65536; </code></pre> which the compiler should optimize into a no-check add. This gets you the same answer on all platforms.

&gt; That’s because I do not think it is universally a good thing that software should crash when an overflow occurs. Think about the software that runs in your brain. Sometimes you experience bugs. For example, an optical illusion is a fault in your vision software. Would you want to fall dead whenever you encounter an optical illusion? That does not sound entirely reasonable, does it? Moreover, would you want this “fall dead” switch to make all of your brain run at half its best speed?<p>If you lived in a world where hackers crafted optical illusions that made you send all your money to them when you viewed them, you would probably want to go blind or some such when you encountered such an illusion.

I found this statement funny:<p>&quot;Moreover, would you want this “fall dead” switch to make all of your brain run at half its best speed?&quot;<p>...because this is actually how our brains work! We are much slower to process and respond to all sorts of stimuli (visual, auditory, conceptual [reading]) when it is contradictory. Think of the feeling you get looking at an Escher sketch.

After chasing strange bugs when using dynamic languages like PHP and JavaScript that keep running by default when minor errors happen (PHP warnings, or undefined variables in JavaScript), I think its good that Swift priorizes safety rather than speed.

&quot;<i>That’s because I do not think it is universally a good thing that software should crash when an overflow occurs. Think about the software that runs in your brain. Sometimes you experience bugs. For example, an optical illusion is a fault in your vision software. Would you want to fall dead whenever you encounter an optical illusion? That does not sound entirely reasonable, does it? Moreover, would you want this “fall dead” switch to make all of your brain run at half its best speed? In software terms, this means that a mission-critical application could crash because an unimportant function in a secondary routine overflows.</i>&quot;<p>That is a ridiculous analogy. What if we replace &quot;optical illusion&quot; with &quot;hallucination&quot;?<p>More importantly, what if there were some sort of middle ground between continuing on as if nothing happened on an error and crashing completely?

I thought it might be interesting to see how this effect changes with the size of the array being summed. How do the relative speeds change when operating out of L1, L3, and memory? Does the lower speed of memory access overwhelm the overhead of the overflow checking?<p><pre><code> $ swift build --configuration release $ cset proc -s nohz -e .build&#x2F;release&#x2F;reduce # count (basic, reduce, unsafe basic, unsafe reduce) 1000 (0.546, 0.661, 0.197, 0.576) 10000 (0.403, 0.598, 0.169, 0.544) 100000 (0.391, 0.595, 0.194, 0.542) 1000000 (0.477, 0.663, 0.294, 0.582) 10000000 (0.507, 0.655, 0.337, 0.608) 100000000 (0.509, 0.655, 0.339, 0.608) 1000000000(0.511, 0.656, 0.345, 0.611) $ swift build --configuration release -Xswiftc -Ounchecked $ cset proc -s nohz -e .build&#x2F;release&#x2F;reduce # count (basic, reduce, unsafe basic, unsafe reduce) 1000 (0.309, 0.253, 0.180, 0.226) 10000 (0.195, 0.170, 0.168, 0.170) 100000 (0.217, 0.203, 0.196, 0.201) 1000000 (0.292, 0.326, 0.299, 0.252) 10000000 (0.334, 0.337, 0.333, 0.337) 100000000 (0.339, 0.339, 0.340, 0.339) 1000000000(0.344, 0.344, 0.344, 0.344) </code></pre> Code is from <a href="https:&#x2F;&#x2F;github.com&#x2F;lemire&#x2F;Code-used-on-Daniel-Lemire-s-blog&#x2F;tree&#x2F;master&#x2F;2016&#x2F;12&#x2F;05" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;lemire&#x2F;Code-used-on-Daniel-Lemire-s-blog&#x2F;...</a> with modification to loop over the different array lengths. Numbers are for Skylake at 3.4 GHz with swift-3.0.1-RELEASE-ubuntu16.04. Count is the number of 8B ints in the array being summed. Results shown were truncated by hand --- I wasn&#x27;t sure how to specify precision from within Swift. The execution with &quot;cset proc -s nohz&quot; was to reduce jitter between runs, but doesn&#x27;t significantly affect total run time. The anomalously fast result for the L3 sized &#x27;unsafe&#x27; &#x27;unchecked&#x27; is consistent.

Site is down, cached here: <a href="http:&#x2F;&#x2F;webcache.googleusercontent.com&#x2F;search?q=cache:MYG52quo1u8J:lemire.me&#x2F;blog&#x2F;2016&#x2F;12&#x2F;06&#x2F;dont-assume-that-safety-comes-for-free-a-swift-case-study&#x2F;" rel="nofollow">http:&#x2F;&#x2F;webcache.googleusercontent.com&#x2F;search?q=cache:MYG52qu...</a><p>EDIT: It&#x27;s back up

I don&#x27;t get the same numbers he gets. The reduce version is the same speed as the simple for loop. He must have made a mistake somewhere.

How do languages which aim to replace C (such as Rust) deal with this issue?<p>Now I agree, your average webapp won&#x27;t see any benefit by removing checks and will see security features by keeping them in, so I&#x27;m all for it.<p>But in OSs (or browsers), speed <i>does</i> matter. And there&#x27;s no way to optimize it (every + or array operation involves an if).<p>Is this just one of the &quot;costs of doing business&quot;?

A factor of three for addition is probably not really significant in most programs.

I see a number of posts that proudly claim (in different forms) &quot;fail early and fast&quot; like it&#x27;s a good thing to simply do a run-time crash always, and even that the article author is &quot;misguided and inflammatory.&quot;<p>I don&#x27;t agree with both claims.<p>Regarding the first, as an example where the crash is definitely not the solution, see the planteen&#x27;s post:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13117170" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13117170</a><p>Or consider that once you use the computers to calculate the real life stuff (like the movement of your car, or even the spaceship 50 million kilometers away) the worst thing you can do is introduce the &quot;fatal discontinuities&quot; in the processing.<p>Regarding the second, allow me to just roll my eyes. The politics is not allowed this week on HN, but the political approaches start to be used automatically. Please just write which his claim is wrong. Labeling is destructive.