Wrong result with scatter += (Not a bug, just a misusing, found by Tullio.jl)

[N5N3]

using LoopVectorization
function func_avx()
    J = [1 1 1]
    A = [i for i in 1:10]
    B = ones(2,10)
    @avx for i in eachindex(J)
        for j in axes(B,2)
            B[J[i],j] += A[j]
        end
    end
    B
end
function func()
    J = [1 1 1]
    A = [i for i in 1:10]
    B = ones(2,10)
    for i in eachindex(J)
        for j in axes(B,2)
            B[J[i],j] += A[j]
        end
    end
    B
end

and the result

func() return
2×10 Array{Float64,2}:
 4.0  7.0  10.0  13.0  16.0  19.0  22.0  25.0  28.0  31.0
 1.0  1.0   1.0   1.0   1.0   1.0   1.0   1.0   1.0   1.0
func_avx() return
2×10 Array{Float64,2}:
 2.0  3.0  4.0  5.0  6.0  7.0  8.0  9.0  10.0  11.0
 1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0   1.0   1.0

If I misusing somthing, close it directly.

[chriselrod]

You can't write to the same place in parallel.

[chriselrod]

@N5N3, as I said in the Tullio issue, I think this is a problem in documentation.

LoopVectorization's README states in the "Warning" section at the top:

3. Are not relying on a specific execution order. @avx can and will re-order operations and loops inside its scope, so the correctness cannot depend on a particular order. You cannot implement cumsum with @avx.

Any suggestions on a better way to explain this so people can understand/expect this issue whenever length(unique(J)) != length(J)?

[N5N3]

It seems that i mis-understood simd before,

I thought the scattering += is a sum, as the re-order is ok.

By the way, if we can't write to the same place in parallel (and simd is a kind of parallel), why @avx is ok for sum?

[mcabbott]

Iterating in the wrong order would indeed be OK, but doing different steps in parallel is much worse, as several of them can start from the same old value, instead of from each other's outputs.

Summing can be done safely, it runs a number of separate accumulators in parallel, and then adds them at the end.

Is there at the moment a way to tell LoopVectorization to leave index i alone, but feel free to vectorise along index j?

[chriselrod]

Is there at the moment a way to tell LoopVectorization to leave index i alone, but feel free to vectorise along index j?

I'll add that feature as I make changes in the next few weeks.
I'll give the users much better control over its behavior.