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

    → Europe/Zurich
    Virtual (Zoom)

    Virtual (Zoom)
    Stefan Roiser
    Hide

    # Madgraph dev meeting Mon 07.03.2022

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

    ## Andrea's slides

    Discussion
    - Use golden epochX4 for the comparison of abstraction layers
    - Go in steps: comparison, Fortran, while NLO will be in 2023 or even in 2024
    - DS: go ahead and merge it, we can fix things later on if needed
    - DS: interesting results, interesting that they differ between processes
      (AV: note that physics results are exactly the same)
    - DS: a bit surprised that eemumu seems factor 2 slower, it seems as fast for me
      AV: please cross-check that, it is useful if we can do this more than one person
    - NN: actually am now using the latest code base, not golden epochX4
      SR: if possible it would be nice to use golden epochX4

    ## Round table

    ### DS

    DS: made a wiki about abstraction comparison

    ### TC

    TC: we should discuss what we want to do with ICHEP
    Proceedings should be short and sweet, while a full paper should give all details.
    Maybe at ICHEP we can discuss the matrix for performance portability, and only a hint at performance.
    March 31st is the deadline for the abstrcat.
    The paper may be fue on begining of the conference July 6th.
    SR: ok Taylor write an abstract

    TC: note also working with sherpa about using kokkos ther.
    Do we want to have something together?
    OM: not clear if we have enough overlap with sherpa

    AV/SR: agree full paper can come later on

    ### NN

    NN: updated sycl branch to get it up to date with latest cudacpp
    Checked results against CUDA and they are the same for all the processes I tried

    Only checked performace for ggttgg, on A100 the sycl is only 4% slower
    By adding restrict kywords, can recover the full performance,
    this may be due to sycl not having constant memory

    On V100 instead Cuda is 1.5x faster for ggttgg!

    Can also go back to epochX4 and port changes there.

    AV: do you keep native cuda/cpp alongside sycl (as David did for alpaka) or only have sycl?
    NN: no, only have sycl

    AV: and do you have it only for gpu (as David for alpaka) or can have both GPU and CPUs?
    NN: can target both actually
    SR: do you have a README?
    NN: there is some stuff in the sage actually,
    see https://github.com/nscottnichols/madgraph4gpu/tree/master/epochX/sycl

    ### LF

    LF: nothing to add

    ### WH

    WH: moving kokkos to newer codegen (from before epochx4 to epochX4)

    Had to add some keys to export_cpp because kokkos needs inline
    OM: did you push to bazaar branch?
    AV: maybe can use the plugin replace_dict mechanism
    OM: indeed we can use that

    AV: look at https://github.com/madgraph5/madgraph4gpu/blob/3762f46b424856c41e1d04e46464cb98b59303db/epochX/cudacpp/CODEGEN/PLUGIN/CUDACPP_SA_OUTPUT/model_handling.py#L908
      replace_dict = super(export_cpp.OneProcessExporterGPU,self).get_process_function_definitions(write=False)
    The point is that write=False means you get the dictionary as output, not the file

    ### SH

    SH: nta for coe

    SH: one suggestion for AV, maybe just running out of device memory,
    just attach the debugger and you might see that
    AV: will open an issue, but do not foresee doing more work on it myself

    ### CV

    CV: testing alpaka, need a boost, where can I find that?
    AV: export BOOSTINC=/cvmfs/sft.cern.ch/lcg/releases/LCG_101/Boost/1.77.0/x86_64-centos7-gcc10-opt/include

    ### OM/SR

    (OM - technical issues speaking on the mike)
    SR: discussed with OM about alphas, decided to delegate that to lhapdf
    Then Fortran will pass to C++ a vector of "G's" which are the alphas essentially

    SR: question to OM/AV, will we always stick to contant alphas?
    I need a class member somewhere...
    AV: would suggest to have this in the plugin and in the standallone
    (even if you pass a vector of all 1s, you still allow vector changes)

    AV: note by the way that this means Nathan's issues with conctsntas is no longer relevant,
    as these things are no longer constant...

    SR: also worked on a cmake version (but no AVX vectorization)

    SR: discussed with TC that we will have a discussion with HepCCE people in two weeks

    SR: we wre looking for a phd student, a bit complicated this round, we'll have it in fall

    ## AOB

    AV/SR absent on Monday 21/3, propose 28
    OM not there on 28

    Then propose Tuesday 22/3 at 3pm - agreed!

    There are minutes attached to this event. Show them.