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 (+/…

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

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

How to “zip” two slices efficiently

cristicbz August 27, 2015, 1:17pm 13

Ooooh, awesome!

Topic		Replies	Views
Optimizing away bounds checks when zipping two iters of the same length help	10	407	March 15, 2026
Why this simple code is not autovectorized by llvm? help	9	2185	January 12, 2023
Performance difference between iterator zip and skip order	7	2557	January 12, 2023
Surprising Auto-Vectorization/Optimization Behavior	6	2949	January 12, 2023
Unable to optimize bounds checks help	24	2201	April 22, 2022

How to “zip” two slices efficiently

Related topics