Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allocation overhead on multiple replications of Quantum TNs #221

Open
mofeing opened this issue Oct 18, 2024 · 1 comment
Open

Allocation overhead on multiple replications of Quantum TNs #221

mofeing opened this issue Oct 18, 2024 · 1 comment
Labels
good first issue Good for newcomers performance Makes the code go "brrrr"

Comments

@mofeing
Copy link
Member

mofeing commented 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 a TensorNetwork like in the following code:

function Enzyme.onehot(x::MPS)
    x0 = zero(x)
    return collect(Iterators.flatten(map(tensors(x0)) do t0
        return map(Enzyme.onehot(t0)) do t1
            replace(x0, t0 => t1)
        end
    end))
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.

image
@mofeing mofeing added the performance Makes the code go "brrrr" label Oct 18, 2024
@mofeing
Copy link
Member Author

mofeing commented Oct 18, 2024

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 _ in 1:1_000_000]) / 1024^2
7.629432678222656

@mofeing mofeing added the good first issue Good for newcomers label Oct 18, 2024
@mofeing mofeing changed the title Allocations overhead on multiple replications of Quantum TNs Allocation overhead on multiple replications of Quantum TNs Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers performance Makes the code go "brrrr"
Projects
None yet
Development

No branches or pull requests

1 participant