A way to turn off all bounds checks (for exploring optimisation potential)?

This would obviously be incredibly unsafe. But is there a way to straight up disable all bounds checking when building with Rust?

I'm interested in knowing what the potential for optimisation is in my program, to be able to determine if eliminating bounds checking is even worth going after. This is difficult to profile with traditional means (such as perf) since the bounds checks are smeared all over the program (and not really attributable to a specific function or line).

This is obviously not something I would use for an actual production build of the program, but if you have some benchmark that you know is normally safe, it should be possible to compare it with a build with the bounds check eliminated (assuming the program is determinstic etc)

1 Like

There isn't any easy way to do this. One possibility is to make a wrapper type around Vec that skips bounds checks in Deref/DerefMut.

That would only affect Vec, not slices, correct?

It seems it would be a useful (presumably perma-unstable) flag to have though, possibly on a per-crate level. Do you know if there have been any prior discussion about such a thing?

You could try patching the relevant panic entry points in std with unreachable_unchecked and compile with panic_immediate_abort (which will allow them to be inlined) and hope that all the branches get optimized out since they're now unreachable.

1 Like

If your test doesn't rely on std, there's no need to patch std; you can make the #[panic_handler] of a #![no_std] build do unreachable_unchecked. Last time I checked, that did successfully result in panics being optimized away as assumed unreachable.

If you just want to hit bounds checks, it needs to be done by the compiler to avoid also compromising other asserts. I recall someone doing basically this test somewhat recently (with results being mostly insignificant and showing we're doing a good job optimizing out unnecessary bounds checks), but I don't recall how they went about executing the test. (Sorry.)

3 Likes

The problem isn't that it would be unsafe (it wouldn't), but that it would be unsound (precisely because it wouldn't be unsafe).

As such, I can't imagine the language ever allowing this in its current state, although it is technically very possible.

Maybe if we extend the notion of safety and soundness to compiler flags? I generally find that idea outright disastrous, because experience shows that people don't expect build settings to affect the correctness of their programs – and rightfully so. But it could probably be made mathematically/technically satisfying.

1 Like

Well, the whole idea is to have a perma-unstable unsafe compiler flag. No one is expected to depend on it for anything (...reliably) .

You will have to change to unsafe { a.get_unchecked(i) } manually.

Alternatively, check the compiled code. Deep knowledge of assembly is not necessary if you can recognize when loops don't use SIMD and have jumps to begin_panic:

2 Likes