-
Notifications
You must be signed in to change notification settings - Fork 0
22 November 2024
-
In the Gauge actions, there are two main components coming from the integrator. The first is
update_P
which leads toderiv
and then toStaple
and from there to a bunch of CShifts (I think?) inGrid/qcd/utils/WilsonLoops.h:306
. The second isupdate_U
which leads toupdate_field
and from there toProjectOnGeneralGroup()
inGaugeImplTypes.h:135
. See more information in https://github.com/UCL-ARC/Grid/issues/7#issuecomment-2488166196 Last week it was suggested we look intoProjectOnGeneralGroup()
, but this is far smaller than what comes from theStaple
side of things (according to the profiles). Should we focus on this or look more into theStaple
? Could you run us through what happens insideStaple
(again, you can find that inGrid/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 onProjectOnGeneralGroup()
.
- Answers:
-
I'm still working on trying to remove the gparity-related tests programmatically based on
if BUILD_GPARITY
insidetests/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.
- Answers: disabling gparity-related tests inside