And if you are convinced you don't need a bounds check and the compiler does not remove it you can explicitly remove the bounds check, provided you mark the access as unsafe. So Rust is a strict improvement over C in this regard.
> The real-world performance impact of bounds checks is surprisingly low.
> The greatest impact I’ve ever seen on real-world code from removing bounds checks alone was *15%,* but the typical gains are in *1% to 3% range,* and even that only happens in code that does a lot of number crunching.
> You can occasionally see greater impact (as we’ll see soon!) if removing bounds checks allows the compiler to perform other optimizations.
> Still, performance of code that’s not doing large amounts of number crunching will probably [not be impacted by bounds checks](https://blog.readyset.io/bounds-checks/) at all.
It is, of course, not universally applicable, so read the post for full details: https://shnatsel.medium.com/how-to-avoid-bounds-checks-in-ru...
How it works exactly I don't know, and apparently it's so complex that it requires over 9000 lines of C++ to express:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Anal...
The idea is pretty simple. You can build a list of known facts based on control flow, explicit __builtin_assumes, and undefined behavior relations. For example, if you've got this code:
if (x < N) {
// In this block, we know that x < N
} else {
// ... and in this block we know that x >= N!
}
> and apparently it's so complex that it requires over 9000 lines of C++ to express
The two main reasons for that is that a) there is a lot of rules covering cases like "we know the result of count_leading_zeroes can be no more than the number of bits in an integer" and so forth, and b) this is doing a lot more logic than just tracking integer comparisons: there's tracking known-bits of integers, maximum possible value, floating-point comparisons, pointer object references.
Even better: if `x` and `N` are integers, then we can infer that `x` < 4. :)
for i in 0..v.len() {
v[i] += 1;
}
My case is a bit outside that, so I don't think the compiler can deduce that. I have a file format which tells me the expected number of fields about a category, and I throw an error & abort if the number is not exactly that.
Also, these data structure fields are always sent in as const variables, so they are never modified (making them "sealed" in a sense), hence I don't need to bounds check on arrays and vectors storing them.
But if it's possible for someone to muck with the file contents and lie about the number of fields which would cause a bounds error, that's exactly what bounds checking is supposed to avoid. So either bounds checks will be removed, or they're necessary.
> But if it's possible for someone to muck with the file contents and lie about the number of fields.
You can't. You can say you'll have 7, but provide 8. But as soon as I encounter the 8th one during parsing, everything aborts. Same for saying 7 and providing 6. If the file ends after parsing 6th one, I say there's an error in your file and abort. Everything has to checkout and have to be sane to be able to start. Otherwise you'll get file format errors all day.
The rest of the pipeline is unattended completely. It's bona fide number crunching (material simulation to be exact), so speed is of the essence. Talking about >1.5 million iterations per second per core.
Strictly speaking I don't think the distance between creation and consumption matters. It all comes down to what the compiler is able to prove at the site where the bounds check may go.
For example, if you're iterating over a Vec using `for i in 0..vec.len() { ... }` then the amount of code between the creation and consumption of that Vec doesn't matter, as the compiler has all the information it needs to eliminate the bounds check right there.
The code I have written is a 3D materials software which works in >(3000x3000) matrices, and I do a lot of tricks with these to what I get from them. However, since everything creating them are validated during their creation, nothing breaks and nothing requires checks. Because most of the data is read-only (and forced by const correctness throughout the code).
I think at that point it'll come down to the compiler's value range analysis as well as how other parts of the program affect inlining/etc. Hard to say exactly what will happen.