There's a discussion of "delayed bounds checking", but not "hoisted bounds checking", where bounds checking is done early. Consider<p><pre><code> let mut tab: [usize;100] = [0;100];
...
for i in 0..101 {
tab[i] = i;
}
</code></pre>
This must panic at i=100. Panic becomes inevitable at entry to the loop.
Is the compiler entitled to generate a check that will panic at loop entry?
The slides suggest that Rust does not hoist such checks, and, so, with nested
loops, it has trouble getting checks out of the loop, which prevents vectorization.
Rust's safety model is in an awkward position of being already complicated enough that adding proofs for skipping bounds checks probably will not happen for a long time, even though this kind of low-level operation is where a lot of optimisation is lost.<p>Compounding on this, Rust is also unstable underneath, since there is no public, stable contract for carrying high-level semantics from HIR into MIR. Because these high-level invariants are lost during compilation, the compiler cannot easily use them to prove and eliminate low-level safety checks. And even if it could, Rust relies on LLVM's language-neutral SCEV, which will never become a good target for carrying these kinds of invariants.
If I followed, Rust's memory safety guarantee means sacrificing roughly ~3% performance with some worst case paths being ~15% (compared to C++ performance)?
That's on the typical performance for bounds checking in C too.<p>But no, "memory safety" includes most of the things discussed on the slides, and those number are for bounds checking only.