Christoph, some thoughts. Good idea to clarify. For v collectives, we have the choice of “must” or “may” synchronize… in the limit of a few non-zero counts, seems clear that May is useful and must is more work. As the MPI application, if the operations may synchronize, the application has to assume it but cannot exploit it. If it is must, then the application can exploit it. In either case, the algorithm can exploit the ability to synchronize. If we allow must to become may for v collectives, we should offer a must version too, since the embedded barrier may be more efficiently done inside the operation. Then the app chooses what is right for them. Neighbor collectives also merit discussion. Example: When implementing v collectives on top of RMA or shmem (persistent mode easiest to use with RMA) we do the cross group sync, even if some counts are zero. If we have further optimizations in persistent mode, we might avoid the whole group… also, likely with neighbor collectives. Regards, Tony Anthony Skjellum, PhD 205-807-4968 On Feb 16, 2026, at 1:32 PM, Christoph Niethammer via mpi-forum <[email protected]> wrote: External Email Warning This email originated from outside the university. Please use caution when opening attachments, clicking links, or responding to requests. This Message Is From an External Sender This message came from outside your organization. Dear all, I would like to present and read PR 1141 "Add text clarifying collective synchronisation-semantics to description" (https://urldefense.us/v3/__https://github.com/mpi-forum/mpi-standard/pull/11...). It implements the feedback from the Oct. 2025 non-voting MPI Forum meeting discussion on the topic raised in issue 971 (https://urldefense.us/v3/__https://github.com/mpi-forum/mpi-issues/issues/97...). Best regards Christoph Niethammer -- Dr.-Ing. Christoph Niethammer High Performance Computing Center Stuttgart (HLRS) Nobelstrasse 19 70569 Stuttgart Tel: ++49(0)711-685-87203 email: [email protected] https://urldefense.us/v3/__https://www.hlrs.de/people/christoph-niethammer__... _______________________________________________ mpi-forum mailing list [email protected] https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi-...