Add hash for FusionTreeBlock to fix cacheing behind AdjointTensorMap permutes

[leburgel]

Potential first step to addressing #516.

The cache underlying permutes of AdjointTensorMaps ( GLOBAL_FSBRAID_CACHE) never gets a single hit, making it effectively useless. This cache uses keys generated from a FusionTreeBlock, but Base.hash wasn't defined for this type causing literally all keys to miss. Adding the hash improves the performance of permuting AdjointTensorMaps with non-Abelian sector types.

Running the reproduction script from #516 gives:

Reproduction script

using TensorKit, BenchmarkTools
using TensorKit.VectorInterface: One, Zero

p = ((2, 3), (4, 1))

function compare(name, V)
    t   = randn(ComplexF64, V ⊗ V ← V ⊗ V)
    adj = t'         # AdjointTensorMap
    mat = copy(t')   # identical space and contents, but a genuine TensorMap

    Vdst    = TensorKit.permute(space(mat), p)
    dst_adj = similar(mat, Vdst)
    dst_mat = similar(mat, Vdst)

    # NB: permute(::AdjointTensorMap, p) unwraps the adjoint and is therefore NOT affected.
    # The slow path is the in-place one, which is what `tensoradd!`/`blas_contract!` use.
    f_adj() = permute!(dst_adj, adj, p, One(), Zero())
    f_mat() = permute!(dst_mat, mat, p, One(), Zero())
    f_adj(); f_mat()
    @assert convert(Array, dst_adj) ≈ convert(Array, dst_mat)

    b_adj = @benchmark $f_adj() samples = 500 seconds = 10
    b_mat = @benchmark $f_mat() samples = 500 seconds = 10
    println(rpad(name, 14),
            " adjoint ", round(minimum(b_adj).time / 1e6; digits = 4), " ms (", b_adj.allocs, " allocs)",
            "  tensormap ", round(minimum(b_mat).time / 1e6; digits = 4), " ms (", b_mat.allocs, " allocs)",
            "  ratio ", round(minimum(b_adj).time / minimum(b_mat).time; digits = 2), "x")
end

compare("fZ2",    Vect[FermionParity](0 => 8, 1 => 8))
compare("fZ2xU1", Vect[FermionParity ⊠ U1Irrep]((0,0) => 4, (1,1) => 4, (0,2) => 3, (1,-1) => 3))
compare("SU2",    Vect[SU2Irrep](0 => 4, 1//2 => 4, 1 => 3, 3//2 => 2))

# needs SUNRepresentations
using SUNRepresentations
compare("fZ2xU1xSU3", Vect[FermionParity ⊠ U1Irrep ⊠ SU3Irrep](
    (0, 0, SU3Irrep(0,0,0)) => 2, (1, 1, SU3Irrep(1,0,0)) => 1,
    (0, 2, SU3Irrep(1,1,0)) => 1, (1, 3, SU3Irrep(1,1,1)) => 1))

After

sector type	adjoint	TensorMap	ratio	allocs (adjoint / TensorMap)
fℤ₂	0.0784 ms	0.0580 ms	1.35×	129 / 65
fℤ₂ ⊠ U(1)	0.1302 ms	0.0360 ms	3.62×	669 / 317
SU(2)	1.1759 ms	0.4083 ms	2.88×	7 864 / 2 847
fℤ₂ ⊠ U(1) ⊠ SU(3)	0.6915 ms	0.0527 ms	13.12×	8 011 / 652

Before

sector type	adjoint	TensorMap	ratio	allocs (adjoint / TensorMap)
fℤ₂	0.0717 ms	0.0539 ms	1.33×	122 / 58
fℤ₂ ⊠ U(1)	0.1232 ms	0.0319 ms	3.86×	794 / 310
SU(2)	2.4282 ms	0.3382 ms	7.18×	27 094 / 2 840
fℤ₂ ⊠ U(1) ⊠ SU(3)	3.8169 ms	0.0465 ms	82.08×	43 529 / 645

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
src/fusiontrees/fusiontrees.jl	96.66% <100.00%> (+0.01%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Jutho]

Is just returning h in the empty case a good idea? Or should we e.g. return the equivalent of an empty tuple, hash((), h) ?

[Jutho]

Clearly, adding this hash function is a no-brainer. This is really a major oversight.

One off-topic question that comes up, thinking about the isempty case. Is it problematic that, if we create a FusionTreeBlock from sectors that don't have a single compatible fusion tree (this must be in the multifusion case), that we cannot recover the sectors and isdual flags?

[lkdvos]

That's actually a very good point. I think currently we are guarding most of the code to never enter this part when there are no fusiontrees (these objects are typically generated from indexmanipulation loops, where we know everything has at least one channel, since it is from a valid tensor).

This did make me check the codebase, and we do actually have one spot where this can be an issue (properly denoted hack):

TensorKit.jl/src/fusiontrees/duality_manipulations.jl

Line 613 in a9094b7

# TODO: this is a bit of a hack to fix the traces for now

where we would now end up with colliding hashes because these only have a single fusiontree, so I've reworked the implementation to just hash the first fusiontree pair, which is again a hack but might be worth it to remain like that until I properly fix that "hack" of the traces. (See #522)