4 ms·
I think LLVM is smart enough to optimize regular `for i in 0..stuff.len()` loops into the same assembly as `for i in &stuff` loops in almost all cases. I imagin
by oconnor663 4y ago
I think LLVM is smart enough to optimize regular `for i in 0..stuff.len()` loops into the same assembly as `for i in &stuff` loops in almost all cases. I imagine this sort of "we can tell that i is always less than len" optimization is a big contributor to the low cost of bounds checks. In some large portion of cases where they're not needed, the optimizer can already see that.
- brundolf 4y agoYeah, I wondered about those too. Less straightforward than pure iterator usage but still plausible
- ridiculous_fish 4y agoIME loops with induction variables (integer indexes) often produces better codegen than with iterators. Compare the these two Rust functions for inverting bits: https://rust.godbolt.org/z/cE4vPdbdY https://rust.godbolt.org/z/cE4vPdbdY This got improved in Rust 1.65 just this month, but the point stands. edit: ARM64 compilation is even sillier. https://rust.godbolt.org/z/PEsbeGxWP https://rust.godbolt.org/z/PEsbeGxWP
- akshaykarthik 4y agoInterestingly enough, with `-C opt-level=3` both functions yield the same assembly. I wonder if there's some pass that's missing or not done at the lower opt level.
- masklinn 4y agoMight be a problem of the number of pass repetitions, where O2 does not rerun the vectorisation after whatever manages to unroll everything but O3 does.