Helicity recycling implementation for CPU builds

[Qubitol]

Helicity recycling can speedup the matrix element, but may have a non-negligible impact on memory usage.

So, it is worth exploring the possibility of implementing it for only CPU builds (with vector instructions).

[oliviermattelaer]

So here they are two strategies:

1. like fortran (detect non zero helicity and regenerate a code based on that information):
2. update ALOHA routine to do the folding within aloha routine (an idea, I'm testing so far)

I have implemented both at standalone fortran level for comparison:

g g > g g g — NCOMB = 32 (ntry = 100000, best of 3)

Mode	Hel computed	Time (s)	Speedup vs standard
standard	32	8.83	1.00×
--unrolhel	32	4.56	1.94×
--hel_recycling (no warm-up)	32	4.32	2.04×
--hel_recycling (warm-up)	20	2.99	2.95×

g g > t t~ g g g — NCOMB = 128 (ntry = 2000, best of 2)

Mode	Hel computed	Time (s)	Speedup vs standard
standard	128	19.39	1.00×
--unrolhel	128	13.32	1.46×
--hel_recycling (warm-up)	128	11.09	1.75×

All 128 helicities contribute, so the warm-up prunes nothing here — the gain is
pure wavefunction recycling + P1N split.

p p > e- ve~ mu+ vm j j QCD=0 — merged EW, subprocess P1_QQ, NCOMB = 256 (ntry = 20000, best of 2)

Mode	Hel computed	Time (s)	Speedup vs standard
--unrolhel	256	8.24	0.20× (5× slower)
standard	256	1.64	1.00×
--hel_recycling (warm-up)	6	0.74	2.22×

The fixed-chirality leptons/neutrinos make 250 of 256 helicities zero. The warm-up
drops them, so --hel_recycling is ~11× faster than --unrolhel — which is itself
5× slower than standard on this merged process.

[Qubitol]

It's nice, just so I understand better:

• the hel_recycling is the Fortran approach?
• the warmup basically calculates the zero helicites in a separate call, so that then it knows it can drop them immediately?
• the unrolhel is the new folding idea?

[oliviermattelaer]

Yes hel_recycling is the current Fortran approach (which is clearly the best).
and unrolhel is "bigger aloha routine" that handles loop over helicity internally.

hel_recycling is the best because it has a warm up phase and therefore the full information (that unrolhel tries to catch-up at run-time).

Based on that, it is clear that hel_recycling is the best. I have tried to combine both (so hel_recycling with unrolhel method). But so far the gain in speed are either negligeable or leading to a slower code (up to 8% slower).
One advantage is the smaller code size (i.e. less line in matrix_optim.f) and faster compilation.

This being said, the compilation time can be speed-up by a factor of at least 5 by:

1. splitting the amp computation in a dedicated file and compile that file with -O0 (with no impact on speed)
2. split the amp computation in different chunk (to avoid the super-linear dependence of the compiler).

So compilation time might not be that relevant anymore. So I'm still evaluating way to move forward with the unrol idea (maybe limit it only to 4 point vertex?)