Hacker News Reader

Comment by gameswithgo | Hacker News Reader

I wonder if some of the bounds checks could be eliminated by using iterators instead of loops? It is common when coming from C to Rust to sometimes avoid complicated iterators because you imagine it can't be fast, so you use a loop, but usually the iterator really is faster.

And I believe the checked math can be eliminated just by explicitly stating you want to use unchecked math. It doesn't require unsafe to do so.

View on HN

>I wonder if some of the bounds checks could be eliminated by using iterators instead of loops

It can and often is. Don't use [] to index into data if you can afford not to. Anecdotally, rustc is also much better at generating SIMD-friendly code with iterators than idiomatic C/C++, but that depends largely on what you're doing.

As an aside, I seem to recall .NET making an interesting optimisation here, such that if you access an array using, for example, `data[20]`, bounds checks are omitted for lower indexes.

Rust and/or LLVM will make this optimization as well. The easiest example I can find of this is in the buffered IO code [1], but there have been others

[1]: https://github.com/rust-lang/rust/blob/f0b58fcf03391a91f7422...

There's a similar pattern in rust:

    fn loop(a: &[u8]) {
        assert!(a.len >= 20);
        for x in (0..20) {
            let y = a[i];
            //Do something with y
        }
    }

Adding the assert before the loop will remove the bounds checks happening on each iteration.

Source?

Anyone asking for "source" should be able to prove that they've not searched first. Because it's right there. As noted in the other comment it's in the literal documentation for rust.

Low effort commenting is usually shunned here, yet the ever prevalent "source?" seems to get a free pass all the time.

Really people should say: "source? Because I tried https://www.google.com/search?q=rustc+is+also+much+better+at... and found no sources whatsoever about this issue that has been discussed to death on dozens of forums yet I was somehow incapable of finding a single thing on the matter"

Why should someone spend time typing out easily searchable content for you? In fact, why should forums with a focus on high quality content even answer you?

Anyone who asks for sources should be required to do the same on demand. Whenever, wherever.

I've certainly seen requests for sources used obnoxiously by people who felt zero need to back up their side of the argument with sources. But it's also often a legitimate request to see what the OP is talking about.

The internet is vast. I sometimes have difficulty finding things I personally saw before and know exist. Slightly different search terms can turn up drastically different results and, with five million visitors per month to HN, it is a melting pot of people with vastly different backgrounds.

Well I mostly agree when the first Google result answer the claim.

I've clicked on most links from your Google query and was not able to find something that prove Anecdotally, rustc is also much better at generating SIMD-friendly code with iterators than idiomatic C/C++ Most of the links are about explicit SIMD, something that is off topic with the initial claim and something that c/c++ do far better (so many SIMD libs), and are also better at hybrid SIMD (SPMD, OpenMP 5,o penACC, etc).

"Anecdotally, rustc is also much better at generating SIMD-friendly code with iterators than idiomatic C/C++" The author talk about auto vectorization. Firstly c/c++ supports AVX512 while rust do not (in stable at least) Secondly real world llvm/gcc dev are paid to improve c/c++ performance, rust performance improvements are only a side effect. And iterators in c++ are idiomatic and I see no reason why rust iterators would auto vectorize better than c++ ones. And c++ do not enforce bounds check (but allow it with at(), anyway bounds check are a totally useless concept because they slow down release performance and capture far less information for debugging than ASAN) So the initial claim is non obvious and I see no answer on the Google query. If nobody is able to prove it I will believe the claim is probably wrong.

Sorry for the confusion. "Anecdotally" as in it's a personal anecdote, I've seen it in my own code.

Could it not be an educational tool to the person asked that when they write a statement of a certain kind a source citation should really accompany it?

https://llogiq.github.io/2017/06/01/perf-pitfalls.html

https://doc.rust-lang.org/1.30.0/book/second-edition/ch13-04...

I see no comparison about rust vs c++ performance in general nor about auto vectorization.

Integer overflow checks are disabled by default in release builds, the author noted they were explicitly enabled in this project for additional safety.

(This is just for the normal operators, if you use e.g. checked_add() or wrapping_add() then you can be explicit about what behavior you want.)

[edit: oops, the overflow checks were only enabled for a separate test, see note from the author below]

It's worth observing that signed integer overflow is undefined in C but defined in Rust, which can impose an additional cost.

C: https://godbolt.org/z/CDha8-

Rust: https://godbolt.org/z/DlN3uf

No, we don't run with overflow checks by default; the overflow check performance analysis is a separate test.

iterators had a lot of work done on them for this reason. although it doesn't always work.

eg, once the difference between using a sign and unsigned value in a loop was causing tustc to not be able to optimize out the checks and resulted in terrible performance for that loop, but it was non-trivial to figure this out

Reply on news.ycombinator.com