Go to the Indico Home Page Oldest event Older event Up to category Newer event Newest event Printable version
 
Focus on:  Hide Contributions
  • Compact style
  • Indico style
  • Indico style - inline minutes
  • Indico style - numbered
  • Indico style - numbered + minutes
  • Indico Weeks View
    • Switch to the management area of this event
    Login

    Madgraph5 GPU development - !! ATTENTION TUESDAY !!

    → Europe/Zurich
    Virtual (Zoom)

    Virtual (Zoom)
    Stefan Roiser
    Hide

    # Madgraph dev meeting Tue 31.05.2022

    Present: AV (notes), CV, NN, DS, TC, WH, OM, SH

    ## Round table

    ### TC

    TC: ntr, worked with Nathan who will report.
    Will soon update kokkos to the latest branch running, also to be ready for event generation.

    TC: do we want to plan a fall NLO workshop? Something like a kickoff for the new challenges.
    OM: should first finish LO, we saw we are discovering things on the way...
    There are more matrix elements at NLO, relatively close to what we do today for LO.
    Then we have the issue of the loops, which we might handle as done today, "forget about it and we are fine"
    (unlike Sherpa that calculates the loop at every event, we compute it much less...).
    The integrator for NLO is completely different (derived from vegas at LO, from MINT at NLO).
    For the rest, the biggest issue is how to prepare the data in phase space integration for GPUs.

    AV: any plans already to travel?
    TC: not yet but we can plan

    ### WH

    ntr

    ### CV

    ntr, was working on other projects, still need to update the alpaka build instructions

    ### DS

    ntr

    ### SH

    ntr, back from a workshop

    ### AV

    Presents slides

    OM: had not understood the NB_PAGE_MAX/NB_PAGE_LOOP exactly, thought AV was doing something different
    Was actually thinking of NB_PAGE small to 32-64 and then a second parameter for the number of pages
    Wanted to have age size small to take decisions on it
    But then we send many pages of 32-64 to the GPU
    AV: this could be interesting for extending to 500k without explosing memory?
    SR: do we need to keep all these arrays after the ME calculation?
    OM: for many of them yes, but could probably refactor this later on... need to look at this again

    OM: about the simplification of the color algebra, not sure that BMA=AMB... is M symmetric?
    SR: not sure it is symmetric...
    AV: so far it works for all processes... ok will check again...

    OM: is test issue #14 related to color and helicity?
    AV: probably not, also fortran only

    OM: this week will probably push the bazaar branch to git, so you can do pull requests

    OM: actually for helicity filtering eventually we need to do option 2b!
    This is mainly because with helicity filtering we need to precompute the list of helicities.
    Then within that we might have to put LIMHEL=0...
    OM: fully agree that the physics is puzzling and a bit worrying, need to think about it a bit
    (not sure why it was introduced, but maybe it was for numerical stability more than for computing speedup)

    AV: but then 2b we change the bridge api to pass helicities?
    OM: for the moment go to 1 as it is the easiest

    NN: about tensor core, asked some experts about support in sycl, it is coming with double precision,
    for the moment in sycl it is there but only in single precision

    ### OM

    nta

    ### NN

    Shares screen on PR #471.
    A lot of useful changes on abstraction layers.
    AV: ready to be merged?
    NN: yes touches alpaka kokkos sycl, also cudacpp but only in golden stuff

    Shares screen on eemumu plot.
    AV: can you change groouping to group by device?
    AV: can you upload some of these plots if not in NDA?

    For GPUS: Sycl (and also kokkos) seem to be faster than native cuda in most cases
    (remember this is epochX4, it is an older version of the code).

    For CPUs: sycl seems to be much faster than native cpp.
    AV: note however that by default cpp uses a single core, I disabled the OMP stuff.
    Will check if it is disabled in epochX4 or not.

    TC: keep in mind that we as a dev team need to finalise what to show to ICHEP.
    So in particular we need to converge on what to show for multithreading.
    AV: absolutely...
    There were some issues in OMP to be sorted out
    see https://github.com/madgraph5/madgraph4gpu/issues/196

    TC: keep in mind that one message we want to give is are the frameworks mature to do a single implementation.

    ## AOB

    AV: probably could go to ICHEP if no one else goes, but to be discussed in the CERN team still

    AV: ICHEP is soon, 5 weeks away! should i stop cudacpp work and focus on abstraction layers?

    OM: should have three messages
    abstraction layers are mature and competitite
    gpus are competitive (throughput per watt)
    unweighted event generation is possible

    AV: about gpus i would insist less on watts, even if very interesting
    I would more insist that GPUs are a perfect fit for MonteCarlos
    TC: would be great to have throughput per watt for us and for the funding agencies,
    but for ICHEP maybe we do not really need that yet
    For instance if people can use their GPUs for MC event generation and save CPUs for geant

    AV: Would like to have some quantitative results about speedup from multithreading
    and speedup for vectorization for each of the various technologies we are using
    NN: will try to dig out if it is possible to do these comparisons

    TC: how about using the skylake as a reference for that?
    AV: can I get an account there?

    ## Next meeting?

    TC: can we meet next Monday?
    AV: not Monday, holiday, prefer Tue
    OM: ok Tue, but prefer Wed
    AV: will send an announcement proposing Wed and as a backup Tue

    There are minutes attached to this event. Show them.