In #56 we notice that the Spin_Spin measurement is too slow.
Naively the cheapest we could imagine would be something that cost V=L^2, a fixed cost per separation. Then volume averaging would bring the total cost to V^2 = L^4.
The current worldline implementation has a cost independent of the separation, but it does that by making that cost ~V so that the total cost is V^3 ~ L^6! The stencil approach means there's a lot of 0s being multiplied with some links and then included in the sum. But that's V amount of arithmetic to evaluate a sum on links over a path. And since we always take the taxicab path the longest the path can be is ~L. Given the path approach and the volume averaging we could get down to L^5. That's still not as good as an FFT method or something like that. But it's better!
With this PR on my machine measuring on 1000 configurations of a 20x20 lattice goes from 440s to 44s, a factor of about 10. So there might be another factor of 2 to be gained but the answers are floating-point equal for 10x less.
The previous implementation was moved to SlowSpin_Spin. I think I now have optimal scaling given the method, so this closes #56.
In #56 we notice that the Spin_Spin measurement is too slow.
Naively the cheapest we could imagine would be something that cost V=L^2, a fixed cost per separation. Then volume averaging would bring the total cost to V^2 = L^4.
The current worldline implementation has a cost independent of the separation, but it does that by making that cost ~V so that the total cost is V^3 ~ L^6! The stencil approach means there's a lot of 0s being multiplied with some links and then included in the sum. But that's V amount of arithmetic to evaluate a sum on links over a path. And since we always take the taxicab path the longest the path can be is ~L. Given the path approach and the volume averaging we could get down to L^5. That's still not as good as an FFT method or something like that. But it's better!
With this PR on my machine measuring on 1000 configurations of a 20x20 lattice goes from 440s to 44s, a factor of about 10. So there might be another factor of 2 to be gained but the answers are floating-point equal for 10x less.
The previous implementation was moved to SlowSpin_Spin. I think I now have optimal scaling given the method, so this closes #56.