22 November 2024

To ask:

1. In the Gauge actions, there are two main components coming from the integrator. The first is update_P which leads to deriv and then to Staple and from there to a bunch of CShifts (I think?) in Grid/qcd/utils/WilsonLoops.h:306. The second is update_U which leads to update_field and from there to ProjectOnGeneralGroup() in GaugeImplTypes.h:135. See more information in https://github.com/UCL-ARC/Grid/issues/7#issuecomment-2488166196 Last week it was suggested we look into ProjectOnGeneralGroup(), but this is far smaller than what comes from the Staple side of things (according to the profiles). Should we focus on this or look more into the Staple? Could you run us through what happens inside Staple (again, you can find that in Grid/qcd/utils/WilsonLoops.h:306).

   • Answers: Staple only does memory accesses, so what we're seeing means that that part of the code is memory bound. If this is still the case for GPUs, then we should optimise them. But for now for CPU, focus on ProjectOnGeneralGroup().

2. I'm still working on trying to remove the gparity-related tests programmatically based on if BUILD_GPARITY inside tests/forces/Makefile.am. Is this the right way to do it or should it be done in the test code itself? Any advice? Would this be something we should look into for other 'disable-able' features so that disabling something also disables all the tests that depend on it? Progress is slow on that as my attempts require new compilations and test runs which take a good hour until it reaches that spot (combined).

   • Answers: disabling gparity-related tests inside tests/forces/Makefile.am is the right way to do it, we don't want to litter a bunch of tests. Also, it's not in scope for this project to fix the build system for all possible cases.