Skip to content

May 20 2024

Carl Pearson edited this page May 20, 2024 · 5 revisions

Attds: Carl, Alex Dutka, Evan, Joseph Schuchart, Gabriel, Matthew Dosanj Vivek Kale

Note-taker

Carl

General Topics

Working Groups

  • Kokkos Comm
    • Have some initial discussion about backends (serial + MPI + NCCL maybe?)
    • Have some initial discussion on initialization and finalization
    • Had some good discussion about MPI wait interactions with Kokkos fence
      • best option seems to be implicitly associating communications with a stream, and wait does not guarantee a fence.
    • Carl is proposing a generic host-side API for different non-contiguous data strategies #64
      • I foresee needing to refactor this in the presence of different communication backends
    • Alex Dutka is proposing a low-level object oriented API #50
    • Carl doesn't have a problem with a bit of API experimentation and churn for the time being since we don't have any users. Ultimately it may be good to let some users with provisional interest guide our decisions (Alex may be one of these initial users).
  • Application Usecases
    • Interest from Arborx (Andrey Prokopenko @ OLCF)
    • Cabana may be an interesting use case as well
  • Modern C++ / MPI
  • Accelerator-Initiated Communication / Support
  • Smart NICs

Notes

  • Carl (see Working Groups above)

  • Evan

    • Working with Jan and Nicole (now at Sandia!) on NCCL
      • Carl: let's keep Alex in the loop on this one
  • Alex

    • Request for reviews and comments on #50
    • Will open an issue to track what his application needs (not open-source yet, maybe open-core eventually)
  • Gabriel

    • MPI init and finalization, PR coming using MPI Sessions
      • Session -> Communicator -> Group
        • Joseph: session model may protect from some MPI finalization stuff
        • Other backends may not support "Sessions" per se.
      • Some global state (per rank) which may be nice
      • Cannot rely on C++ destructors
        • MPI_Finalize
        • Kokkos::finalize
      • Could have a "default" communicator like the Kokkos default execution space instance
  • Joseph

    • Monitoring and weighing in on design
    • propose: object that holds resources for a particular communication, somewhere between MPI_Request and persistent
      • represents a datatype, a buffer, etc, but not bound to a peer
  • Matthew

    • just monitoring things for now
  • Vivek

    • interested in device-initiated communication
    • Working on Kokkos Tools, let's not miss any opportunities.
      • Tools has some per-MPI-process profilers now