Consider removing `--check-bounds=no`?

[Keno]

I think we should consider removing the --check-bounds=no option.
I can't really think of any situation in which it would be safe or sensible to turn it on.
If you really must have something like it, a Cassette pass that disables bounds checking
in a particular region of code, could achieve any residual benefits without being as massive a footgun.
Worse, turning on --check-bounds=no on current master can actually result in significantly
worse performance because it removes inference's ability to do concrete evaluation (constant folding).
Note that that we can make the option a noop in a minor release since throwing a BoundsError
is allowable undefined behavior.

EDIT: note for future readers that the recommended replacement is to mark @inbounds code that is discovered to benefit from this flag from @profile analysis.

[matthias314]

Here is a case where I regularly use --check-bounds=no: I write a program that does some computation, say based on some integer parameter n. The larger n is, the longer the program runs. I want to get the result for as large a value of n as possible. I run the program for small n with bounds checking turned on to make sure everything works. Then I turn bounds checking off to push n as high as possible. That's quick and easy and does the trick for me.
(This is of course for code that I use myself, not for packages released to the public.)

[vtjnash]

Just to be clear, the reason we want to remove it is it requires us to compile the code more conservatively, leading to significant losses in inference accuracy, leading to significant losses of performance when running with check-bounds=no

[JeffBezanson]

@matthias314 Out of curiosity, what kind of speedup do you get?

[gbaraldi]

Triage discussed this in length and the conclusion was that issues that are present in --check-bounds=no are similarly present with @inbounds meaning that this is probably a bandaid.
One idea @oscardssmith proposed but wasn't sure of the feasibility is to refine the inbounds effect to not taint if we can prove that the acesses are always inbounds.

[vtjnash]

That sounds easy to prove: just remove --check-bounds=no and the required property is proved exactly when expected, and more often than it could be proven under --check-bounds=no in the current system (e.g. we can eliminate taint on bounds more easily with check-bounds=yes/auto than with check-bounds=no. That is the statement of purpose for this issue.)

[matthias314]

@JeffBezanson The speedup varies; often it is indeed not impressive.

My point was not so much about the effectiveness of the current implementation of --check-bounds=no, but about the general idea: Instead of sprinkling my code with @inbounds, @boundscheck and @propagate_inbounds, I find it easier not to worry about it when I write my code and then turn all checks off once I think my code is correct.

[LilithHafner]

leading to significant losses of performance when running with check-bounds=no

Could we get a specific example of @inbounds and/or check-bounds=no decreasing performance? I feel like there should be an open issue for this but I'm having trouble finding either a gh issue or an example of this behavior.

[oscardssmith]

julia> Base.@assume_effects :terminates_locally function f(s)
           t = 0.
           for i in 1:2^20
               for m in 1:length(s)
                   t += 1/(i + s[m])
               end
           end
           t
       end
f (generic function with 1 method)

julia> Base.@assume_effects :terminates_locally function f_inbounds(s)
           t = 0.
           for i in 1:2^20
               for m in 1:length(s)
                   @inbounds t += 1/(i + s[m])
               end
           end
           t
       end
f_inbounds (generic function with 1 method)

julia> g() = f((2,3,4))
g (generic function with 1 method)

julia> g_inbounds() = f_inbounds((2,3,4))
g_inbounds (generic function with 1 method)

julia> @btime g()
  0.861 ns (0 allocations: 0 bytes)
37.903821175206865

julia> @btime g_inbounds()
  2.683 ms (0 allocations: 0 bytes)
37.903821175206865

So a nice example where @inbounds a 3 million times regression.

[LilithHafner]

Thanks! I figured out the reason I couldn't reproduce this is that I wasn't using the latest master.

[maleadt]

Apparently there's GPU users that care about this, because GPUs are very sensitive to the branch-heavy code introduced by bounds checks (typically because it increases register pressure which hurts occupancy) and they are using unoptimized kernels that don't have the necessary @inbounds annotations. At the same time, --check-bounds=no is now (on 1.9) unusable to the because the regression in const-prop breaks static compilation, so that's not great.

@Keno Can you elaborate on the Cassette-like solution? What's a reasonable way to implement this for GPUCompiler's abstract interpreter without the const-prop regressions?

[omlins]

The feature check-bounds=no is one of the top beautiful things of Julia in my opinion: it allows to develop code with the benefit of bounds checking, and once everything works as it should, with a single switch we can remove the bounds checking not necessary anymore to have it run faster. I think there is a large community, in particular domain scientists (who in the end are the probably largest part of the target users) that will strongly appreciate if this feature can be conserved. :)

[vtjnash]

The biggest security flaw in C come from the fact it does not have bounds checking enabled in releases.