Update in March 2017 Rust now implements .zip() specially for a couple of core iterators, including slice iterators (iter and iter_mut) as well as a few adaptors of those (map, cloned, zip, maybe more). For these iterators zip will now provide satisfactory loop optimization, for example allowing fo…

I went on a similar exploration trying to improve dot product some time ago. I found that rustc isn't great at unrolling loops, so manually unrolling gives a signficant speed boost: // I'd love it if this were the fastest version :( fn naive_dot_product(x: &[f64], y: &[f64]) -> f64 { x.iter().z…

That's strange, I have this testcase which vectorizes in glorious fashion. Only obvious difference is integer vs. float. #[bench] fn zipdot_checked_counted_loop(b: &mut test::Bencher) { let xs = vec![0; 1024]; let ys = vec![0; 768]; let xs = black_box(xs); let ys = black_box(ys); …

For some reason, the float version just doesn't optimize like the integer version does. Is this a "-ffast-math" type of problem? Llvm doesn't want to do the vectorization since it may change the floating point result slightly(?) Edit: It's a -ffast-math type of problem, documented here test zipdo…

Closing the link loop: This issue tracks adding some kind of fast-math semantics to Rust, possibly using a wrapper type.

Great find! It's sad that it doesn't at least get unrolled though (since that should keep the float operation order, right?)

That's a good point, it should be unrolled.

This looks a lot like it is being compiled without optimizations. Here are the times I get with a recent rustc (1.4.0-dev (84e50ca14 2015-08-16): Small vectors: Non-Optimized: test bench_index ... bench: 8,154 ns/iter (+/- 52) test bench_naive ... bench: 9,138 ns/iter (+/- 86) t…

Arggh, serves me right for not using cargo... I'm used to cargo bench magically putting in optimization flags. Here are my optimized numbers (rustc -O --test dotprod.rs && ./dotprod --bench). Less impressive speedup, but still very significant: test bench_index ... bench: 231 ns/iter (+/…

Does LLVM's Inductive Range Check Elimination pass pick this pattern up?

How to “zip” two slices efficiently

uncategorized

bluss August 18, 2015, 12:37pm 10

You found a way to write an unrolled loop where bounds checks are elided anyway, that's really nice.

Topic		Replies	Views
Optimizing away bounds checks when zipping two iters of the same length help	9	509	December 15, 2025
Why this simple code is not autovectorized by llvm? help	8	2271	December 12, 2016
Performance difference between iterator zip and skip order uncategorized	6	2631	March 4, 2018
Surprising Auto-Vectorization/Optimization Behavior uncategorized	5	3011	December 21, 2017
Unable to optimize bounds checks help	23	2352	January 22, 2022

How to “zip” two slices efficiently

Related topics