You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had to implement Enzyme.onehot to make forward-differentiation work with Enzyme/Reactant.
Thanks to the replace, we can reuse the arrays that are unchanged when doing multiple replications + minor modifications of a TensorNetwork like in the following code:
function Enzyme.onehot(x::MPS)
x0 =zero(x)
returncollect(Iterators.flatten(map(tensors(x0)) do t0
returnmap(Enzyme.onehot(t0)) do t1
replace(x0, t0 => t1)
endend))
end
The number of allocations should be in the order of the number of elements, which for my case is currently a 10 site MPS of physical dim = 2 and max bond dim = 32... so 2778 elements. However, @time reveals that the allocation count is in the order of millions!
julia>@time Enzyme.onehot(ψ₀);
0.134450 seconds (1.92 M allocations:119.125 MiB)
@profview_allocs points to the implementation inds(tn; set=:open). Such method is being called by copy which calls the Quantum constructor.
The text was updated successfully, but these errors were encountered:
A posible solution might be to use sizehint! together with ninds at the start of the count, and then shrink allocation using sizehint! again.
Even in the abnormal case where we have 1 million indices, the memory overhead of such preemptive allocation would be around 8 MiB... which is totally ok.
julia> Base.summarysize([gensym() for _ in1:1_000_000]) /1024^27.629432678222656
mofeing
changed the title
Allocations overhead on multiple replications of Quantum TNs
Allocation overhead on multiple replications of Quantum TNs
Oct 18, 2024
I had to implement
Enzyme.onehot
to make forward-differentiation work with Enzyme/Reactant.Thanks to the
replace
, we can reuse the arrays that are unchanged when doing multiple replications + minor modifications of aTensorNetwork
like in the following code:The number of allocations should be in the order of the number of elements, which for my case is currently a 10 site MPS of physical dim = 2 and max bond dim = 32... so 2778 elements. However,
@time
reveals that the allocation count is in the order of millions!@profview_allocs
points to the implementationinds(tn; set=:open)
. Such method is being called bycopy
which calls theQuantum
constructor.The text was updated successfully, but these errors were encountered: