Choose timezone
Your profile timezone:
Madgraph5 GPU development
→
Europe/Zurich
Virtual (Zoom)
Virtual (Zoom)
Stefan Roiser
# Madgraph4gpu dev meeting Mon 06.12.2021
Present: SR, AV (notes), SH, OM, CarlV, NathanN, (later) Taylor
## Round table
Stephan: ntr, mainly working on simulation
Carl: ntr, mainly working on hardware
SR: was there any followup to the presentation in CMS?
CV: thanks again to all who attended, but no there was no followup
Andrea: mainly working on API changes in CUDA/C++ to ease integration with Fortran bridge.
- Removed fptype_sv (and neppV) from ~public sigmakin, merged PR,
to make it faster
- Prototyping a MEKernelLauncher class (could be renamed as CPPProcess eventually),
it takes care of allocating the memory buffers of the right type,
of computing good helicities once and of computing MEs each time
- Working on further improvements of the API below
> would keep array decoding in CUDA XXX version but remove it from C++ version
(eventually even CUDA FFV could use global memory arrays if we split into many separate kernels)
> ideally would like to remove ipar from the xxx API, but this may need a reshuflling of AOSOA
as SOAOSOA (ipar being the outermost version)
- Scheduled a meeting with DavidLange for today but had to reschedule it to next week
- Discussed Intel compilers with many others, would be nice to have,
we might need a special build to have sycl with nvidia support, need to clarify this and licensing
NN: you need an own build of llvm/clang (probably you do not ned a special licensing),
see https://github.com/intel/llvm/blob/sycl/sycl/doc/GetStartedGuide.md
SR: following up with openlab about this, opened a ticket to have this on cvmfs supported by openlab
Nathan: opened an issue about complex support for floats, there is some code that seems redundant, seems fixed
- Did some benchmarking and there seems to be no improvement from float over double, something to fix probably.
AV: would suggest debugging this, this could be an issue.
- Some plots normalised by clock speed.
TC: should normalise by maximum flops instead. AV: agree, and very nice idea!
- OM: could also use watts as normalisation.
AV: this is important, but maybe not for us. We want efficiency of the software.
- Also prepared many nice plots of cuda vs sycl vs kokkos on differnt hardware.
Sycl looks very similar to cuda, while kokkos seems a bit slower.
TC: investigating this, it may be due to the kokkos complex class with respect to thrust instead, but maybe not.
TC: probably some remaining differences from small changes between epoch2, epochX etc...
- TC: also get some nans actually out of 270_gpu, not clear why.
OM: a bit surprised about that, in principle it should work out of the box.
- TC: on Sherpa actually got kokkos the same as cuda (see https://arxiv.org/pdf/2106.06507.pdf),
so not clear why in madgraph we see kokkos slolwer.
Note fig 8: above and below 6 gluons you have two different algos which should be used
(one algo is faster below 6, one above 6, green and red crosses in fig 8 - AV: probably the same as fig 3?)
Taylor: nta
Olivier: trying to have the new ME linked to fortran, essentially on the multichanenel part.
At some point I need to pass some arguments to the ME calculation to implement multichannel
(ons additional input which is the channel number, then the output will not be the full ME
but rather the ME times the channel weight for the madevent algorithm).
- Instead of outputting the code in fortran, trying to also do it in c++, so that we stay in sync.
If we have different orders in fortran and c++ this may be a problem and we get different results.
- SR: is this another branch in bazaar? OM: using the one that SR is using for the bridge.
Stefan:
- Continuing work on the fortran bridge for GPU, now finally got a full ME in Fortran and CUDA,
and finally they are excatly the sam ein the two implementations, except for a 15% constant factor.
OM: as discussed last week, this is probably due to the running of alphas
(OM, SR and AV discussed this extensively last week, as well as the multichannel issues).
- Also started to work on interfacing to the C++, there facing the issue mentioned by AV
on removing the vector types from the API. Then hopefully should get also the CPU version.
- For the moment, copied the full code inside. Eventually should rely on external library.
AV: this is related to the MEKernelLauncher I am working on.
SR: yes this is line, idea is that I include many headers, but eventually if I can include one class it is better!
- AV: forgot to say, this MEKernelLauncher is also needed so that all CUDA that neds to be glued together
without RDC relocatable device code can be linked together in one piece, but then this is linked outside.
## AOB
Next meeting?
In two weeks 20 Dec some people (SR, AV) will be off. TC: agree, lets skip that.
- Agree to have general meeting January 10.
- Maybe also a chat between OM, SR and AV on the fortran integration end of next week
There are minutes attached to this event.
Show them.