@dotdash The two for loops over slices in sum_deque_2 are very efficent, but I've never managed to build a rust iterator that optimizes like that (I guess llvm would have to recognize it as two consecutive loops). .chain() doesn't do it, and simpler or special cases like chain don't. It's a big iterator challenge!

I've run into the same in the ndarray crate. For non-contiguous arrays, the iterator wants to be by row, and then dispatch to the slice iterator for contiguous rows. I haven't been able to make a rust iterator that does this efficiently (I use explicit nested for loops to implement arithmetic ops instead).

Could you clarify which SSE instruction set was used to get that 20x speedup?

On ARMv7 it's 2x before using NEON and 3x after so I'm not sure if it's the best llvm could do here. (possibly material for an llvm bug report)

Even on an old x86 cpu, using SSE (v1) yields a 2x speedup for a total of 5x.

My tested platform is x86-64, Sandy Bridge, but with default settings, so only default instructions used.

It's using paddd, the loop core in sum_deque_2 looks like this:

    f460:       f3 0f 6f 52 90          movdqu xmm2,XMMWORD PTR [rdx-0x70]
    f465:       f3 0f 6f 5a a0          movdqu xmm3,XMMWORD PTR [rdx-0x60]
    f46a:       f3 0f 6f 62 b0          movdqu xmm4,XMMWORD PTR [rdx-0x50]
    f46f:       f3 0f 6f 6a c0          movdqu xmm5,XMMWORD PTR [rdx-0x40]
    f474:       66 0f fe d0             paddd  xmm2,xmm0
    f478:       66 0f fe d9             paddd  xmm3,xmm1
    f47c:       66 0f fe d4             paddd  xmm2,xmm4
    f480:       66 0f fe dd             paddd  xmm3,xmm5
    f484:       f3 0f 6f 62 d0          movdqu xmm4,XMMWORD PTR [rdx-0x30]
    f489:       f3 0f 6f 6a e0          movdqu xmm5,XMMWORD PTR [rdx-0x20]
    f48e:       66 0f fe e2             paddd  xmm4,xmm2
    f492:       66 0f fe eb             paddd  xmm5,xmm3
    f496:       f3 0f 6f 42 f0          movdqu xmm0,XMMWORD PTR [rdx-0x10]
    f49b:       f3 0f 6f 0a             movdqu xmm1,XMMWORD PTR [rdx]
    f49f:       66 0f fe c4             paddd  xmm0,xmm4
    f4a3:       66 0f fe cd             paddd  xmm1,xmm5
    f4a7:       48 83 ea 80             sub    rdx,0xffffffffffffff80
    f4ab:       48 83 c3 e0             add    rbx,0xffffffffffffffe0
    f4af:       75 af                   jne    f460 <_ZN11sum_deque_220hbee41beab497848aadaE+0x2b0>

using -C target-cpu=native, sum_deque_2 improves further, switching to AVX(?) instructions vpadd and so on.

Thanks, just the default SSE2 indeed.

Do you think it would be useful to create an llvm issue containing IR output from the two platforms side-by-side? The issue is here.

The llvm ARM guy is interested in some more arm data points, care to chime in @emoon, @warricksothr?

Your issue is only tangential to this issue, but you should make a more reduced test case if you only want to look at the loop's codegen. Here's what I'd look at, just the summation, which produces a big blob of autovectorized code on x86-64. https://play.rust-lang.org/?gist=8b542d1b17b8d69e44b7&version=nightly

Thanks @bluss and sorry for the diversion. The fact unrolling is disabled on ARM by default was an interesting discovery. Using the -force-target-max-vector-interleave=4 LLVM option actually produces a small improvement. (and stops there for N > 4)

Triage: No change using the for loop, but due to the fold improvement for VecDeque's iterator, the idiomatic dq.iter().sum() is now as fast as it should be (same as the slice).