Hacker News Reader

Comment by haasted | Hacker News Reader

Footnote 6 is interesting:

“I prefer asserts over comments for this, since the compiler can also see them. The good news is, the compiler can also see that they don't do anything so a lot fewer are present in the binary program. Interestingly, a couple of them allows the compiler to optimize much harder. No, I won't tell you which those are.”

I appreciate the pattern of having “comments” that are equally useful to compiler and reader. And I’m impressed that some compilers actually use them to optimise the output. And I’m slightly baffled that the examples of these are apparently a secret. :)

View on HN

In Rust, an assert can turn multiple bounds checks on array indexing into just a single bounds check. Maybe it's something along those lines here too.

Interesting! Do have a link to an example?

Given the following code (and with optimisations on):

    pub fn no_assert(input: &mut [u8]) {
        for i in 0..10 {
            input[i] += input[i+1];
        }
    }

    pub fn with_assert(input: &mut [u8]) {
        assert!(input.len() >= 11);
        for i in 0..10 {
            input[i] += input[i+1];
        }
    }

The no_assert function ends up doing a bounds check for every iteration, and the with_assert function only does a single check.

Still that assert has to be checked at some point right? I would assume that maybe the compiler could do this optimization without having to be told.

In practice a small function like this would be inlined, which gives room for further optimisations. At any point, if the compiler knows that all accesses are in bounds, it can remove the bounds checks. The trick is actually having it figure that out.

I believe the compiler can't do that, since the bounds check panic is a side effect that can be observed - the message tells which index that failed the check! For that reason, non-elided checks will not be reordered.

However, I believe a future Rust RFC could turn that around and validate the idea that in some cases such things could change execution order, even if it has noticeable side effects.

(No idea if it's technically feasible!)

Interesting! Godbolt if anyone is interested: https://godbolt.org/z/1QlLyG

Both loops get entirely unrolled. Its 5 instructions for each iteration in the first example, and only 3 in the second example. (To say nothing of the fact that conditional jumps are (usually?) much more expensive than add/mov instructions)

https://gist.github.com/kvark/f067ba974446f7c5ce5bd544fe3701...

Go and C++ (when using checked accessors like std::vector::at) can do the same thing. A precondition that satisfies all bounds checks will also eliminate them. You could do this as a post-compile optimization for any language under certain conditions.

I’m interested in how this works in Go, which doesn’t have a built-in assert statement. Do you have somewhere I can read up on it?

The form of "assert" is not important. It is isomorphic with if (a>b) {exit}. The compiler can assume that thereafter a<=b. until one of them is modified.

Reply on news.ycombinator.com