Workplan for January 2022

[valassi]

This is a dump of the things I plan to do in January after the break.

It touches the internal APIs for kernel launchers, the bridge, the memory access, going further to MT, heterogeneous apps and split kernels. All of these things are tightly interconnected.

One of the main ideas of my recent development was the separation of calculations (kernels and kernel launchers), memory buffers (MemoryBuffer.h) and memory access (MemoryAccessMomenta.h and related templated classes).

Another related main point has been allowing host functions also in CUDA (#318). This is related to the idea of a test for the Fortran bridge.

So far this is achieved

• API1 PR API (1) Random number classes - runtime choice of random numbers #317, random number kernel launchers
• API2 PR API (2) MemoryBuffers classes - separate data and computing classes #320, memory buffer classes
• API3 PR API (3) Rambo kernel launchers #321, rambo kernel launchers and new templated memory access classes

This is WIP and very urgent

• API4 PR API(4) Move HelAmps to the latest MemoryAccess classes #322, use the new memory access classes in HelAmps (turn HelAmps functions into header-only templated functions)

The next urgent steps are the following. I have a few bits and pieces of code in various PRs, but some must be reviewed in terms of the above

• API5, a new apimes branch/PR for API (5) Encapsulate the ME calculation in a single class #301 replacing PR WIP: prototype API to encapsulate the ME calculation in a kernel launcher MEKL  #302, matrix element kernel launcher classes (differently from 302, separate MemoryBuffers in a separate class): I assume this will still be with SIMD MEs in gcc and CUDA MEs in nvcc (no SIMD host MEs in nvcc) [PS May 2023: done in MR API(5) MatrixElement kernel launcher (and ME buffers and mememory access) #324]
• API6, bridge, completing PR WIP: move Stefan's bridge into core CUDA/C++ directory #315 (reimplement that in terms of the MEKL of API5), add a --bridge option to check.exe with random/rambo on host, transpose to fortran momenta buffers, then launche the bridge on host or on device [PS May 2023: done in MR API(6) Integrate Stefan's Bridge in core CUDA/C++ and develop bridge tests #325]

More forward looking, a tiny bit less urgent, but toghtly related

• API7, "full SA workflow" class, encapsulating the stuff that is now in check_sa.cc (but also in runTest.cc): start from no input and come up with ME averages and full events
• API8, use the above API7 to implement host multithreading SA, multi-GPU SA, heterogeneous SA (replacing PR WIP - het + klas2 + epoch1/epoch2 (Heterogeneous standalone application: GPU + SIMD CPU) #159)
• API9, add MemoryAccessWavefunction classes, add MemoryBufferWavefunction classes, modify HelAmps with a second WV_ACCESS template class parameter to implement kernel access to wavefunction buffers from xxx/ffv functions, use all of this for splitting the calculate_wavefunction kernel (PR WIP - Split kernels and more #242) and possibly for color algebra on tensor cores (Color algebra optimisations (use tensor cores?) #155, Monitor the use of tensor cores #118)

A few other points that are at the level of wishes, to be reevaluated, and in any case not urgent

• Should fptype/cxtype become also template parameters, specifically in xxx/ffv functions in HelAmps? Not urgent (but it would be nice to allow a bridge test with rnd/rambo in double and the MEs in float, for instance)
• Similarly, should fptype_v or just neppV become a template parameter in xxx/ffv? This is related to multi-SIMD executables Multi-SIMD-mode executables? #177
• Allow host calculations of MEs also in nvcc?
• Vectorize also rambo?

On a completely different level, something to be done when API6 is complete and would profit from API7 and API8:

• Prepare a new BMK SA application for hepix benchmarking, certainly using ggttgg instead of eemumu, certainly using a better MT (OMP multithreading gives very unstable and suboptimal throughputs on pmpe04 (eemumu, May 2021 software) #196), certainly fixing scalability issues (Understand scalability issues (crash from 12 to 120 iterations) in BMK container #251), and possibly using heterogeneous workloads

Voila... Andrea

[valassi]

I have completed today

• step API4 in API(4) Move HelAmps to the latest MemoryAccess classes #322
• step API5 in API(5) MatrixElement kernel launcher (and ME buffers and mememory access) #324 (I will close the older WIP: prototype API to encapsulate the ME calculation in a kernel launcher MEKL  #302)

[valassi]

I have now also completed today

• step API6 in API(6) Integrate Stefan's Bridge in core CUDA/C++ and develop bridge tests #325 (I will close the older WIP: move Stefan's bridge into core CUDA/C++ directory #315)

This completes the first big chunk of PRs. I will try to present these on Monday so that we can merge them. Then the remaining points I discussed above are still todo, I might work on them next week.

[valassi]

I have merged one more PR

• step 7a about cross section kernels in API(7a) CrossSection kernels #326, this is just encapuslating the ME averages, not a full workflow, but provides yet another lego brick for that - note also that this probably fixes Understand scalability issues (crash from 12 to 120 iterations) in BMK container #251 as it removes a large array that grows with the number of iterations

[valassi]

I would say that the main issues descibed here, ie points API1 to API6, have all been implemented - essentially in the timescale foreseen: API6 was merged in Jan 2022.

Many issues that were more bvague and forward looking at the time, eg API7 to API9 and beyone, remains open, but with different meaning s now that we focus on madevent.

I think this is completed and can be closed.