# Probabilistic bounds-checking idea, to retain more (probabilistic) safety, and retaining most of the speed

**URL:** <https://discourse.julialang.org/t/probabilistic-bounds-checking-idea-to-retain-more-probabilistic-safety-and-retaining-most-of-the-speed/78515>\
**Category:** General Usage\
**Created:** [March 26, 2022, 4:24pm UTC](https://discourse.julialang.org/t/probabilistic-bounds-checking-idea-to-retain-more-probabilistic-safety-and-retaining-most-of-the-speed/78515 "2022-03-26T16:24:48Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [March 26, 2022, 4:24pm UTC](https://discourse.julialang.org/t/probabilistic-bounds-checking-idea-to-retain-more-probabilistic-safety-and-retaining-most-of-the-speed/78515/1 "2022-03-26T16:24:48Z")

</div>

First, I like Julia’s approach to bounds checking, it seems ideal, better than most, in fact all, languages I know of.

My own idea: `@inbounds` could be relaxed to check say every 4th loop iteration (configurable by the user?), to lessen overhead. Your code is still less safe, but you retain at least some safety. Seemingly the code would expand, but you may have expansion anyway, it’s common for compilers to unroll loops.

Background: Julia is mostly not made to be a safe language, while it is by default regarding bounds checks (but not e.g. overflows). And then you can to off locally with `@inbounds` by the programmer (or globally, by the user, or force always on despite `@inbounds`).

If you do turn of bounds checking (globally, or even in just one place) locally in your program, the program in no longer safe, i.e. it depends on the analysis of the programmer being right (and possibly inputs to the program).

Then the best you can hope for is a crash, rather than incorrect calculations.

I got the idea, while reading (and answering at) this thread on Rust (a language made to be safe above all, safer, really than Java):

> [@Comparison of Rust to Julia for scientific computing?](https://discourse.julialang.org/t/comparison-of-rust-to-julia-for-scientific-computing/78508):
>
> I had some students come ask me about implementing material from my numerical analysis course (which used Julia) in part of their Rust student group. I’m not an expert, but my feeling is that Rust is a “safer” language, which to me means it must be slower. That is, Rust is designed for “systems” where safety is more important than speed. Also, I believe the landscape for scientific computing packages in Rust is no where as developed as compared to Julia. Anyone with more experience with Rust kn…

See also:  
[https://www.sciencedirect.com/science/article/pii/S0167404819302457](https://www.sciencedirect.com/science/article/pii/S0167404819302457)

> we propose CHOP, a [Convex Hull](https://www.sciencedirect.com/topics/computer-science/convex-hull) Optimization based framework, for bypassing redundant memory bounds checking via profile-guided inferences.

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [March 26, 2022, 5:40pm UTC](https://discourse.julialang.org/t/probabilistic-bounds-checking-idea-to-retain-more-probabilistic-safety-and-retaining-most-of-the-speed/78515/2 "2022-03-26T17:40:06Z")

</div>

I think we can actually do one step better. Bounds checks are mostly free unless they prevent vectorization, so simply allowing the compiler to switch the order of bounds errors would allow for most of the required speedup. (Also doing things like checking every 4th element strictly would mean that you have a roughly 1 in 4 chance of missing common errors like off by 1)

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [March 26, 2022, 8:23pm UTC](https://discourse.julialang.org/t/probabilistic-bounds-checking-idea-to-retain-more-probabilistic-safety-and-retaining-most-of-the-speed/78515/3 "2022-03-26T20:23:16Z")

</div>

Yeah. One of my plans for the new LoopVectorization would be to have the semantics be that if code throws an error, it is allowed to move that error earlier in the program.  
Thus, it would be allowed to hoist bounds checks out of and in front of loops, checking them (and possibly throwing an error) before entering the loop.

This would only work in cases where bounds are inferable, e.g. affine loop nests that can be represented as a polyhedra.  
It would work less well for loops like

```julia
for i in 1:N
    for j in 1:innerlooplengths[i]
        A[j,i]
    end
end

```

but you could still hoist the checks out of the `j` loop.

Things like LUTs would be harder to infer the range for, plus even if you do infer the range, it doesn’t mean it’ll actually index the full range, so you could throw a `BoundsError()` incorrectly, meaning I don’t see a way to do this correctly for LUT-like indexing at the moment.