Repository navigation
Masses/couplings as compile time constants instead of constant memory #39
Description
Hi @oliviermattelaer, this is a followup of our chat this afternoon and a spinoff of issue #23.
We should check again the effect of having masses/couplings in constant memory instead of compile time constants. This commit saves 4 registers (down from 178 to 174)
6679569
Is this because some values are hardcoded to 0? Or is this irrelevant?
If it is because they are 0, then maybe we could move the others to constant memory, but still keep in mind that couplings are only purely real or purely imaginary (is this true?), and thus save the registers, while still allowing variable couplings (in constant memory) that are not hardcoded at compile time.
Thanks, Andrea
Originally posted by @valassi in #23 (comment)
Metadata
Metadata
Assignees
Labels
No labels
Activity
[ep2to2ep1] CPPProcess.cc : epoch1 try to use constant memory for cou…
valassi commentedon Oct 18, 2021
A brief followup on this issue, see #263.
I thought that in the latest eemumu/epoch1 I was using parameters read from file (and set via cudamemcptosymbol into cuda constant memory), but actually I was using hardcoded compile time constants. The confusion comes from the fact that nvcc does not give me a warning (see #263, #264).
Now, I have gone back to reading from files the user-defined values. It is clear that this does affect cuda performance. Certainly, it increases registers from 122 to 128. In addition, the throughput seems a tiny bit slower, say 1-2% slower.
So, all in all, one could eventually think of hardcoding parameters in the code. To allow user-defined parameters, maybe one could simply code-generate some header files instead of card files, where all parameteres are defined as human-readabale constexpr lines. This would allow users to still modify these values (but they would need to do it before building the code, rather than at runtime). I keep this issue open as one idea.
But for the moment I will move the defaults back to reading parameters from file, even if this comes with a tiny performance loss.
[epochX3] Remove hardcoded cIPC/cIPD in manual CPPProcess.cc - cuda r…
[klas3bis] add to epoch1 eemumu the cuda performance regression of ep…
[-]Investigate masses/couplings in constant memory instead of compile time constants[/-][+]Masses/couplings as compile time constants instead of constant memory[/+]valassi commentedon Dec 9, 2021
I have just opened PR #306. I copy the relevant text here
This is a followup to #23 and #39
Yesterday while working on unrelated things (older WIP in klas3/klas3base in eemumu epoch1) I realised there was a performance regression of around 20% in cuda for eemumu between epoch1 and epochX, because epoch1 was using hardcoded parameters while epoch1 was using parameters read from file and then set in constant memory.
I moved also epoch1 to the (slower, but more default) reading f parameters from files. However, I also added the option to use hardcoded physics parameters, bth in c++ and cuda, if an ifdef switches them on. This PR is the result of that.
The implementation is fully functional, but it includes a few hacks which should be improved. The complication comes from the fact that one should use constexpr in the calculation of derived parameters, and there are two issues:
Eventually, the hack of the second issue above should be removed
This PR in any case is now fully functional (not WIP) and can be merged
[cxs] add some constexpr to cxsmpl (as this is needed in madgraph5#39)…
valassi commentedon May 22, 2023
The option to use compile time constants for physics parameters is now fully functional (HRDCOD=1), for instance thorugh MR #306. I would close the older issue #23 where the initial studies were done, for issue cleanup, but I would keep #39 still open for further studies. It is still not completely clear to me when/if one option is sfatsre than the other. In reweighting in any case we need HRDCOD=0, rather than HRDCOD=1. Closing #23 and leaving #39 open.