Slow backward pass when the forward pass touches a large array

[tkf]

Here is a MWE:

julia> function bench(n)
           c = ones(n)
           _, back = forward(p -> c[1] * p, 1)
           @benchmark $back(1)
       end
bench (generic function with 1 method)

julia> bench(10 ^ 3) |> display
       bench(10 ^ 4) |> display
       bench(10 ^ 5) |> display
BenchmarkTools.Trial:
  memory estimate:  7.94 KiB
  allocs estimate:  1
  --------------
  minimum time:     708.962 ns (0.00% GC)
  median time:      772.438 ns (0.00% GC)
  mean time:        1.396 μs (20.10% GC)
  maximum time:     20.507 μs (85.36% GC)
  --------------
  samples:          10000
  evals/sample:     130
BenchmarkTools.Trial:
  memory estimate:  78.20 KiB
  allocs estimate:  2
  --------------
  minimum time:     2.706 μs (0.00% GC)
  median time:      5.779 μs (0.00% GC)
  mean time:        7.328 μs (14.44% GC)
  maximum time:     195.151 μs (95.96% GC)
  --------------
  samples:          10000
  evals/sample:     6
BenchmarkTools.Trial:
  memory estimate:  781.33 KiB
  allocs estimate:  2
  --------------
  minimum time:     32.468 μs (0.00% GC)
  median time:      54.223 μs (0.00% GC)
  mean time:        63.464 μs (12.27% GC)
  maximum time:     1.255 ms (73.20% GC)
  --------------
  samples:          10000
  evals/sample:     1

I see similar effect with an alternative implementation:

julia> function bench(n)
           c = ones(n)
           proj = zeros(n)
           proj[1] = 1
           _, back = forward(p -> (c'proj) * p, 1)
           @benchmark $back(1)
       end

As you can see, computation time of back grows as length(c) grows even though majority of c does not participate in the computation. Is it possible to avoid this problem?

[tkf]

I started wonder if problem like this is unavoidable by design. For example, the adjoint of A::AbstractMatrix * B::AbstractMatrix is defined by

Zygote.jl/src/lib/array.jl

Lines 207 to 209 in d74f3cf

	@adjoint function(A::AbstractMatrix * B::AbstractMatrix)
	return A * B, Δ::AbstractMatrix->(Δ * B', A' * Δ)
	end

Wouldn't it be wasteful if (say) A is a large constant matrix and only B depends on the input (the argument of the outer-most forward call)?

Maybe it is better to use struct-of-pullbacks rather than pullback-of-struct? In the above case, it would be something like

@adjoint function(A::AbstractMatrix * B::AbstractMatrix)
  return A * B, (Δ -> Δ * B', Δ -> A' * Δ)
end

instead. It'd be a bit hard when it turns out that you need to compute derivatives w.r.t all arguments in the end and if some of the computations for them can be shared (see also JuliaDiff/ChainRulesCore.jl#8). But I think that can be solved relatively easily by sharing states between the pullbacks.

Does my argument make sense? Or is there already a similar facility to not compute irrelevant intermediate derivatives?

(The function * in the OP uses the method *(::Number, ::Number) so it is probably not the directly cause. But I wondered if the derivative w.r.t. struct (hence closure) has a similar problem.)

[willtebbutt]

I think the issue is to do with not representing the sparsity in the adjoint properly. We could use a 1-hot-like vector (or variant thereof where the non-zero element is allowed to have any value) for getindex with scalar entries in the first instance.

The issue regarding struct-of-pullbacks vs pullback-of-structs is orthogonal to this I think. We're actually going to move towards Zygote's pullback-of-structs route in ChainRules as it's much easier to share computations between adjoints if you go down this route.

Separately, we have thunks to avoid actually performing certain bits of computation that we don't want. e.g. in the matrix multiplication example, we'll have pullback that when invoked returns two thunks.

[willtebbutt]

Yeah, so if you look at the adjoint for getindex, you'll see that we're literally returning with only one non-zero element in the case that the forwards pass pulls out a single element of the array. This is a prime target for optimisation, and it would be great to see a PR to sort this out, at least in the single-element-index case to start with.

[tkf]

@willtebbutt Thanks a lot for clarifying the current situation around these problems (esp. what is planned around ChainRules and thunk).

But it's still not clear to me if everything in the OP can be explained by getindex. I was vaguely aware of the getindex issue so that's why I mentioned the non-getindex variant. Don't we need another separate fix for c'proj example? (see below for benchmarks)

What I forgot to emphasize was that getindex and c'proj were just easy examples of "touching large array/object." I'd rather want to know if there is a general solution to it (migration to ChainRulesCore maybe?). There are other ways to touch "large objects" (e.g., getproperty, globals, ...).

julia> function bench(n)
           c = ones(n)
           proj = zeros(n)
           proj[1] = 1
           _, back = forward(p -> (c'proj) * p, 1)
           @benchmark $back(1)
       end
bench (generic function with 1 method)

julia> bench(10 ^ 3) |> display
       bench(10 ^ 4) |> display
       bench(10 ^ 5) |> display
BenchmarkTools.Trial:
  memory estimate:  15.88 KiB
  allocs estimate:  2
  --------------
  minimum time:     1.045 μs (0.00% GC)
  median time:      1.712 μs (0.00% GC)
  mean time:        2.718 μs (17.00% GC)
  maximum time:     286.861 μs (98.12% GC)
  --------------
  samples:          10000
  evals/sample:     10
BenchmarkTools.Trial:
  memory estimate:  156.41 KiB
  allocs estimate:  4
  --------------
  minimum time:     10.380 μs (0.00% GC)
  median time:      12.935 μs (0.00% GC)
  mean time:        16.034 μs (12.74% GC)
  maximum time:     1.029 ms (93.46% GC)
  --------------
  samples:          10000
  evals/sample:     1
BenchmarkTools.Trial:
  memory estimate:  1.53 MiB
  allocs estimate:  4
  --------------
  minimum time:     110.699 μs (0.00% GC)
  median time:      129.600 μs (0.00% GC)
  mean time:        162.228 μs (14.29% GC)
  maximum time:     1.541 ms (55.01% GC)
  --------------
  samples:          10000
  evals/sample:     1

[willtebbutt]

Ah I see what you're saying. My immediate response is: do we care about optimising for this kind of situation? This seems like kind of a hard problem to optimise away as, from the perspective of Zygote (which only really gets to reason about what goes on inside for forward) you're computing the dot product between two dense vectors, so there's not a lot else that it could do. @MikeInnes might have a more insightful view on this though.

That said, were you to move the creation of c and proj inside the function in the forward call, I would say you've got more of a point. Then again, I would ask whether you've designed the forwards pass sensibly -- if you designed proj and c to be 1-hot and a Fill respectively, then you should reasonably be able to avoid the scaling issues because you should be able to perform adjoint-local optimisations to get good performance, as opposed to Zygote having to analyse the entire function.

I guess my opinion on the matter is that the asymptotic complexity of the reverse-pass should generally be the same as the forwards pass, and this follows immediately from each @adjoint having the same forwards- and reverse- complexity. So if you've got a situation where there's a single operation who's forward pass is O(1) and reverse is O(N), then there's a problem. That's why getindex is straightforward to fix, but the c / proj example less so.

As regards getproperty: we should be reasonably well optimised there anyway -- representing the adjoint as a NamedTuple of nothings, with one non-nothing element is fine for most things. I'm sure that you could construct a scenario in which there's more overhead than would be ideal, but is it one that we care about?

[tkf]

I think there are other important situations where the interactions with constant variables are not sparse. For example input/output data to the neural nets and the random variables for dropouts and GANs are all constants from the point of view of auto-differentiation. They interact densely with the variables that depend on the "input" with which derivatives are calculated. Furthermore, the size of those constants are comparable to the variables that depend on the "inputs", especially, I think, in the context of "scientific AI" where are the models are not as big as those huge deep neural nets. See also @antoine-levitt's real-application example where this matters JuliaNLSolvers/NLsolve.jl#205 (comment). It looks to me that those cases need structure-of-pullbacks approach (or equivalently thunk-based approach?) to defer the computation until needed.

(Alternatively, I suppose the AD engine can somehow "mark" the values that depend on the "input" during the forward pass so that adjoint function can know with which argument it has to take the derivatives. But this sounds more complicated than structure-of-pullbacks to me.)

Of course, the examples I noted are very basic in machine learning setup so it is very possible that I am just ignorant about existing solutions to them. But I thought there is some non-zero chance that the design of Zygote is not fully reviewed because it is not yet the main auto-differentiation engine of Flux.

[tkf]

Now that I mention GAN, another example is taking derivative with respect to the generator. It is wasteful to take derivative w.r.t discriminator parameters in this case.

[willtebbutt]

Hmm I see your point. In a tape-based system you get to know which variables are involved in AD, and which aren't, for free. In Zygote's world you don't though. One option is to use dropgrad (is that still the name) -- this could be implemented at the Zygote-rule level and used to manually mark up code to say that you don't need to propagate stuff through a particular bit of code. This combined with thunks should get you 90% of the way. Not a great solution, but I don't really know how hard it would be to do the code analysis required to automatically be able to drop gradients. Again, @MikeInnes would know better.

[mcabbott]

Does Zygote know internally which arguments of a function need to be tracked back to gradient's inputs? If so: Could @adjoint could make available some __istracked__(x) roughly equivalent to x isa TrackedArray, to insert near expensive calculations? Could it recognise tuples in Δ -> (dx, dy) and simply not evaluate dx when this is not required? I suppose the second could break something, but surely not many things.

[tkf]

@willtebbutt In JuliaDiff/ChainRulesCore.jl#30, @oxinabox explained to me that that's what thunk is for and how the rules are implemented using it. You've already mentioned thunks but I guess I didn't really get it enough while writing the last comment. Now I'm convinced that thunks solve the issue I brought up.

@mcabbott I was thinking a similar solution too. But I started to think that using thunks can solve most of the problems.

Closing, since #291 will take care of this issue.

[mcabbott]

I see, thanks for the link. Maybe I finally understand what a thunk is, simpler than I imagined.

[willtebbutt]

Now I'm convinced that thunks solve the issue I brought up.

As per my previous comment, I'm not sure that they really do without use in conjunction with more general knowledge regarding whether or not parents (in the computational graph sense) need to compute their own adjoints i.e. via some __istracked__ function as @mcabbott suggests. Again, not sure how that would work in Zygote.