Code-used-on-Daniel-Lemire-s-blog

Given that the title is "Don’t assume that safety comes for free: a Swift case study", I don't think he's being particularly misleading. "Don't assume" usually just means that one should not take something for granted, not that it is never true. And doesn't appending "a Swift case study" makes it fairly clear that he is talking specifically about this case in Swift? Also, he does point out in this paragraph that there is nothing inherently slower about the functional approach: "All these functions achieve nearly the same best performance if you disable safety checks at build time (swift build --configuration release -Xswiftc -Ounchecked). This means, in particular, that we get the fancy abstraction (the reduce approach) for free, as long as we disable safety checks. That makes performance a lot easier to understand." See the Rust benchm

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? $ swift build --configuration release $ cset proc -s nohz -e .build/release/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/release/reduce # count (basic, reduce, unsafe bas