MadMatrix perf me timing

[stloufra]

Timing without D>H H>D copy
Also silencing of standalone warning with clang

[Qubitol]

Thanks! We can merge!

[oliviermattelaer]

Would it not make sense to keep those transfer time?

[stloufra]

The times for the copy D>H and H>D are still available, however now the ME time does not involve the copy itself, which is closer to what production event generation would be like (data already on GPU and because of unweighting small portion of events generated copied to host)

Before:

TotalTime[MatrixElems]  (3) = ( 3.185397e-01 )  sec  (time with copy)
00 GpuInit :     0.215978 sec
1a GenSeed  :     0.000001 sec
1b GenRnGen :     0.019825 sec
2a RamboIni :     0.000002 sec
2b RamboFin :     0.134938 sec
2c CpHTDmom :     0.001071 sec
2d Aosoa2U  :     0.000283 sec
> 3a SigmaKin :     0.032081 sec (was not gpuDeviceSynchronize(), so only launch time)
3b CpDTHmes :     0.286165 sec
4@ UpdtStat :     0.000000 sec

After:

TotalTime[MatrixElems]  (3) = ( 3.179551e-01 ) (time without copy)
 00 GpuInit :     0.211485 sec
1a GenSeed  :     0.000002 sec
1b GenRnGen :     0.015631 sec
2a RamboIni :     0.000002 sec
2b RamboFin :     0.125008 sec
2c CpHTDmom :     0.001068 sec
2d Aosoa2U  :     0.000271 sec
> 3a SigmaKin :     0.317955 sec (right timer)
3b CpDTHmes :     0.000200 sec
4@ UpdtStat :     0.000000 sec

For heavy processes the time difference is negligible as the copy is async and for more events it can be hidden, however, for small it makes difference.

Now thinking about it we may change the name of the timer as it no longer times the SigmaKin but the whole umami call (corresponding to production) so:

• device buffer allocation and free (gpuMallocAsync) < WONT BE THERE AFTER MEM UNIFICATION
• copy_inputs (momenta into MadMatrix’s layout, g_s) < WONT BE THERE AFTER MEM UNIFICATION
• computeDependentCouplings
• helicity filtering (first call)
• sigmaKin kernel
• copy_outputs < WONT BE THERE AFTER MEM UNIFICATION

(v100, g g > t t~ g g, ./check_sa -p 256 256 1)