search

kokkos / kokkos-comm

Experimental MPI Wrapper for Kokkos
https://kokkos.org/kokkos-comm/
Other
12 stars 9 forks source link

What should the name of this project be? #3

Closed cwpearson closed 5 months ago

cwpearson commented 6 months ago

In no particular order:

slug namespace Name champions
kokkos-comm KokkosComm ???
kokkos-mpi KokkosMPI Kokkos MPI Carl
kokkos-messagepassing ??? ???
kokkos-mpi-connector ??? ???
your suggestion here
cwpearson commented 6 months ago

I like kokkos-mpi because really we're talking about implementing MPI (and very similar subsets) for Kokkos. It's simple and gets the point across.

masterleinad commented 6 months ago

I'm fine with kokkos-mpi and KokkosMPI.

dalg24 commented 6 months ago

kokkos-mpi-interop

jczhang07 commented 6 months ago

kokkos-mpi, as in kokkos-kernels

olivier-snl commented 6 months ago

The first two are shorter at least.

cedricchevalier19 commented 6 months ago

I would rather stay away from having "mpi" in the name, so Kokkos-Comm is my favorite because it is shorter.

We can even do a Kokkos-Komm (Kokkos-Komunikare in greek!) is we want to keep up with the k (should we also do Kokkos-Kore) ? More seriously, acronyms like MPI are quite painful to use with standard naming conventions (Mpi vs MPI vs mpi ?).

dssgabriel commented 6 months ago

I agree with Cédric; I think it is best not to have "MPI" explicitly in the name. kokkos-comm is a nice, short name (I believe it was also the first name of this repo?) and the KokkosComm:: namespace isn't too long either.

I am ok with kokkos-komm/KokkosKomm, which works in German ("Kommunikation") as well! Depends on how serious we want this to be :slightly_smiling_face:

hmt23 commented 6 months ago

As Cédric and Gabriel, I prefer Kokkos-comm. The reason is to not have mpi in the name. Maybe we want to have communication semantics that can be implemented in mpi or something else. Kokkos-comm-interop should also be fine to me. Even if the main goal is to be interoperable with MPI, I would prefer one repo for all message passing communication interoperability.

perache commented 6 months ago

I also prefer Kokkos-comm. It is agnostic of the underlying communication layer and thus avoid issues if we want to relax the MPI semantic.

rousseladr commented 6 months ago

It would be better not to depend on the name "MPI", and so I would consider Kokkos-comm

janciesko commented 6 months ago

kokkos-mpi or kokkos-mpi-interop. I'd use kokkos-comm in the future which could include kokkos-mpi, kokkos-shmem etc.. I can live with kokkos-comm even though the title sounds vague to me. Note: one-sided communication is still part of MPI.

rousseladr commented 6 months ago

I think it is better to think now about the common layer for both technologies you mentioned, instead of defining first specialized classes of communication. That is why is would rather chose kokkos-comm

cwpearson commented 5 months ago

Okay, I think we're going with KokkosComm / kokkos-comm:

  1. It keeps the door open to operate outside of MPI, which some of our core constituency wants to focus on (NCCL, shmem, alternative APIs)
  2. Things with "MPI" in the name are often MPI implementations, which we are not.
  3. It does not preclude wrapping MPI, which will be the primary early effort