Slow loop fusion when multiplying a column vector with a row vector

[zsoerenm]

I am using Julia v0.6.0-pre.alpha.34
I run this simple function, which should be fast, because of loop fusion:

function test_perf1()
    range = 1:2000000
    range_transp = collect(range)'
    steering_vector = complex.(ones(4,1), ones(4,1))
    sum_signal = zeros(Complex{Float64}, 4, length(range))
    sum_signal .+=
      steering_vector .*
      cis.((2 * pi * 1.023e6 / 4e6) .* range_transp .+ (40 * pi / 180))
    return sum_signal
  end

This results in:

BenchmarkTools.Trial: 
  memory estimate:  137.33 MiB
  allocs estimate:  19
  --------------
  minimum time:     1.328 s (0.98% GC)
  median time:      1.364 s (2.87% GC)
  mean time:        1.363 s (2.99% GC)
  maximum time:     1.398 s (5.34% GC)
  --------------
  samples:          4
  evals/sample:     1
  time tolerance:   5.00%
  memory tolerance: 1.00%

However, when I remove the dot after cis, I get this result:

BenchmarkTools.Trial: 
  memory estimate:  183.12 MiB
  allocs estimate:  97
  --------------
  minimum time:     440.628 ms (17.45% GC)
  median time:      443.680 ms (17.70% GC)
  mean time:        445.445 ms (17.72% GC)
  maximum time:     458.517 ms (19.00% GC)
  --------------
  samples:          12
  evals/sample:     1
  time tolerance:   5.00%
  memory tolerance: 1.00%

The memory consumption is reduced, but the fused code it 3 x slower

[KristofferC]

Note that the argument to cis is just a scalar.

[zsoerenm]

It is not a scalar. Note that range_transp is included in cis.() .
It is slower because cis is unnecessarily calculated 3 times more often than needed because of the broadcasting with column vector steering_vector as @stevengj notes here: https://discourse.julialang.org/t/why-is-this-julia-code-considerably-slower-than-matlab/2365/62

It it better to create a temp variable first.
I'm closing this for now.

[KristofferC]

Oh, sorry, yes I miscounted the parenthesis.

[StefanKarpinski]

Why close this if there's a real performance issue? The vectorized cis function is deprecated on 0.6, so I'm a bit confused about the bug report here? The deprecated vectorized cis method is almost certainly horribly slow.

[StefanKarpinski]

The output of @code_warntype is quite long and definitely has some ::Any typed variables in it, so I'm going to reopen this as a performance bug.

[stevengj]

@StefanKarpinski, it's not a real performance issue. The programmer has to decide whether it is worth it to allocate the extra storage to call the cis function fewer times.

If you do X .+= colvec .* cis.(rowvec), then it allocates no temporary storage but it calls cis for every output. If you do tmp = cis.(rowvec); X .+= colvec .* tmp then it allocates more storage but it calls cis fewer times (saving a factor of length(colvec)).

[StefanKarpinski]

One really nice thing about the new (c)transpose wrappers is that you can just transpose a range without needing to expand it to a full vector, so the collect in collect(range)' can be removed.

[stevengj]

In principle, the optimal thing would be something like

for j=1:length(rowvec)
    tmp = cis(rowvec[j])
    for i = 1:length(colvec)
        X[i,j] += colvec[i] * tmp
    end
end

which allocates no temporary storage and also calls cis a minimal number of times, but it seems like a hard problem for the compiler to automate this from X .+= colvec .* cis.(rowvec).

[StefanKarpinski]

What about the Any-typed variables in the code_warntype output? I.e. T::Any, A_1@_55::Any, A_1@_152::Any. It doesn't seem like the generated code for this should have any such variables.

[StefanKarpinski]

That sort of optimization is what an @pure annotation for methods that means what people think it should mean would be really useful for – i.e. if you call this again with the same arguments, it will always give the same answer, so feel free to call it as few or as many times as you want and cache results. Of course, that's not what @vtjnash says @pure means, so cis isn't considered "pure".