>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
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.
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?
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.