Zig 2024 roadmap

Posted Feb 5, 2024 15:09 UTC (Mon) by atnot (subscriber, #124910)
In reply to: Zig 2024 roadmap by khim
Parent article: Zig 2024 roadmap

> 10x slowdown is “barely measurable”? What world do you live in?

This is just based on just testing my own programs. Which are generally bottlenecked on memory not integer math, as most programs are. Even then, 10x is a ridiculous number, I can't find anyone reporting anything even close to 2x in real world programs.

But here, let's look at some actual data, someone running specint:

> On the other hand, signed integer overflow checking slows down SPEC CINT 2006 by 11.8% overall, with slowdown ranging from negligible (GCC, Perl, OMNeT++) to about 20% (Sjeng, H264Ref) to about 40% (HMMER). [...]
> Looking at HMMER, for example, we see that it spends >95% of its execution time in a function called P7Viterbi(). This function can be partially vectorized, but the version with integer overflow checks doesn’t get vectorized at all. [...]
> Sanjoy Das has a couple of patches that, together, solve [some missed optimizations]. Their overall effect on SPEC is to reduce the overhead of signed integer overflow checking to 8.7%.
https://blog.regehr.org/archives/1384

Specint is a bit biased towards HPC but we see, even there most normal business logic style code doesn't lose out at all. The losses are dominated by a few, very hot functions that are presumably heavily optimized already.

As you note, overflow checks interfere with vectorization, but so do millions of other things, it's notoriously finicky. Rust regularly misses autovectorization because of bounds checks too. It's very hard to write non-trivial code that vectorizes perfectly and reliably across platforms by accident.

Which gets me to the actual point I was getting at you ignored: In a hypothetical world where overflow checking was enabled by default, here's how this would have gone in a profiling session:

"why is hmmer::P7Viterbi() so slow now?"
"oh, it's not vectorizing because of overflow"
"let me replace it with a wrapping add, or trap outside of the loop body, or use iterators since I'm using Rust"
"that's better"

And millions of mysterious production bugs and a hundred CVEs would have been avoided, at barely any cost to most programmers and one extra profiling iteration of a thousand for a few people writing heavily integer math code.

Zig 2024 roadmap

Posted Feb 5, 2024 15:36 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

> In a hypothetical world where overflow checking was enabled by default

…Rust would have played the role of “new Haskell”: something which people talk about but don't use, except for a few eggheads and then rarely.

> And millions of mysterious production bugs and a hundred CVEs would have been avoided, at barely any cost to most programmers and one extra profiling iteration of a thousand for a few people writing heavily integer math code.

Nothing would have been avoided because Rust would have been just ignored. Rust, quite consciously, used up it's weirdness budget for other, more important, things.

Perhaps Rust with slow-integers-by-default would have saved someone from themselves, but chances are high that it would have hindered adoption of Rust too much: people are notoriously finicky about simple things and seeing these dozens of checks in the program which should be, by their understanding, two or three machine instructions long would have gave Rust a bad reputation for sure.

> This is just based on just testing my own programs.

If you are happy with that mode then why couldn't you just enable it in your code? -Z force-overflow-checks exists precisely because some people like these overflow checks.

I'm not big fun of them because in my experience for hundreds of bugs where some kind of buffer is too small and range checks are catching the issue there exist maybe one or two cases where simple integer overflow check is capable of catching the issue which is not also caught by these range checks. Certainly not enough to warrant these tales about millions of mysterious production bugs (why not trillions if you go for imaginary unjustified numbers, BTW?)

Zig 2024 roadmap

Posted Feb 5, 2024 16:26 UTC (Mon) by atnot (subscriber, #124910) [Link]

> Nothing would have been avoided because Rust would have been just ignored.

You're just making my own arguments back at me now, but snarkier. I said this two messages ago.

Look, I like Rust too, it's my personal language of choice. There's no need for this level of aggressive defensiveness over someone on the internet thinking it would be useful to make some pretty marginal tradeoff differently. With the data we have, I'm convinced it makes sense today and I've explained why. You're welcome to disagree.