Choose timezone
Your profile timezone:
Madgraph5 GPU development
→
Europe/Zurich
Virtual (Zoom)
Virtual (Zoom)
Stefan Roiser
# Madgraph meeting Mon 28.06.2021
Present: Stefan, Andrea, Olivier, Stephan, Laurence, Carl, Walter
Apologies: Taylor
## Round table
Laurence: nothing recent
Looked at vTune profiler about AVX512 to follow up on the report from Andrea,
but could not find anything new apart from what already know/tried.
Saw a big drop in turbo boost of the processor speed (sent a link around with some metrics).
Wondered if we are memory bound but could not see any hint about that in the profiler.
Looks like AVX512 with 256bit registers is good, but the addition of 512bit registers is not,
this is nothing new, essentially a confirmation of what we already know.
- Could be a good thing at the next Intel coffee. SR: maybe July 7th?
LF: will check with Maria and let you know. => todo
- AV: still think there must be a situation where AVX512 and 512bit registers help?
OM: there was a physics code (Dalton?) for which 512bit regiesres looked helpful.
- SR: can you check interfaces and directory structures of sycl port?
Andy had reported that it would be useful to have a standard installation.
- SR: could you also ensure there is a working build for sycl?
Again it would be useful for Andy to try, can you get in touch with him?
LF: sure will do. (SR: Andy away next week however).
LF: note however there are amny other differences, eg sycl uses clang,
there are many factors that influence performance.
- OM: for vectorization and AVX512, would be good to try icpc compiler => todo
[after the meeting: look at https://github.com/madgraph5/madgraph4gpu/issues/220]
- SR: also for vectorization, we should try the new ARM architecture => todo
[after the meeting: look at https://github.com/madgraph5/madgraph4gpu/issues/221]
Carl: some new slides for ggttgg
- there is a clear sweet spot at 160 registers for double precision
OM: please try 164! AV: and 168!
OM: it was from some plot Andrea had shown (https://github.com/madgraph5/madgraph4gpu/issues/26)
- for float single precision, the maximum is rather around 180-216
- also 128 threads seems slightly better than 32 threads per block on T4
- SR: in Andy's plots we did not seem to get a difference
AV: maybe T4 vs V100, could be nice to ask Andy to try the plots => todo
[after the meeting: look at https://github.com/madgraph5/madgraph4gpu/issues/222]
Walter: ntr
Will be on holiday the next two weeks, back on Wed July 14
Stephan
- implemented the CI also for float precision, was quite easy, just one config file to change
(essentially changed the name of the job and added Andrea's option of FPTYPE=f)
- talked to Danilo from CMS about multithreading, he said that presently what we propose
would not fit their mode because they run their own multithreading,
they just want our code to be thread safe... this may change if our code is x20 faster
> AV: thread safety maybe not a problem?
SH: the problem is mainmly from Fortran common blocks!...
> SH: it would be nice to have a discussion here at a Monday meeting
AV: yes very good, either here on Monday meetings or generator WG meetings
SR: or maybe even in frameworks WG meeting
Andrea:
- followed up some issues in clang reported by Stephan (thanks for the help!), still iterating,
NB we were building nvcc against gcc even if clang was set up (now fixed)
- paper is on arxiv, https://arxiv.org/abs/2106.12631, and was sent to EPJWOC proceedings for vchep
- discussion with powheg team, they are interested in improving the software interface to mg
- note an interesting paper from the Sherpa team https://arxiv.org/abs/2106.06507
Olivier: following up on code described last week, still issues with phase space cuts
Stefan: ntr
## AOB
Next meeting?
SR: propose we skip the next two weeks
Ok, agree to have next meeting on July 19th
There are minutes attached to this event.
Show them.