Jeff and friends, A layered implementation on top of C adds no performance path for C++. Only a functional interface . It has to deal with all the limitations inherited from the C interface too. Tony Skjellum On Fri, Sep 12, 2025 at 1:46 PM Ghosh, Sayan via mpi-forum < [email protected]> wrote:

Hi Jeff, From recent discussions in the C++/Languages WG, it was apparent that, we could not reach a consensus on a “normative" interface - application/user needs are multifarious, and most users would rather prefer developing their own ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd Hi Jeff,

From recent discussions in the C++/Languages WG, it was apparent that, we could not reach a consensus on a “normative" interface - application/user needs are multifarious, and most users would rather prefer developing their own C++ solutions over MPI to have better control over application logic such as serialization (reflection, explicit buffering, etc.) and managing object lifetimes. OTOH, members agree that having a barebones C++ interface (like the deleted ones?) may help in designing third-party high-level interfaces. So, proposing a new interface or binding would most likely not serve the broader purpose, and compromises that must be baked in due to MPI semantics may thwart modern C++ developers.

So, through a series of prospective side documents, the plan is to capture general guidelines for designing performant C++ interfaces over MPI (expecting several C++ interface implementations over MPI), considering the dissonance between the models.

--

Sayan Ghosh Computer Scientist Future Computing Technologies Group Pacific Northwest National Laboratory (509)-372-6323 • *https://urldefense.us/v3/__https://sg0.github.io__;!!G_uCfscf7eWS!ajr8hPuv5s... <https://urldefense.us/v3/__https://sg0.github.io/__;!!G_uCfscf7eWS!c9LeMozG_yZM54PFqHqEeSabOx1D-x2QdhfuSPa30JtEl5Cm8QDaniu-dxQy9rQZM_FMJp5AiwMd82gVb70IOBqdpTsxb2X6$>*

*From: *mpi-forum <[email protected]> on behalf of Jeff Hammond via mpi-forum <[email protected]> *Date: *Friday, September 12, 2025 at 1:16 AM *To: *Wes Bland <[email protected]> *Cc: *MPI Forum <[email protected]>, Suggs, Evan < [email protected]>, Uhl, Tim Niklas (SCC) <[email protected]>, Matthias Schimek <[email protected]> *Subject: *Re: [Mpi-forum] Proposal process for a side document for C++ Language Interface for MPI-5.x

Check twice before you click! This email originated from outside PNNL.

This Message Is From an External Sender This message came from outside your organization.

Why do we need a side document? That would be required if we expect multiple implementations. That makes a lot of sense for Memory Allocation Kinds because we want that capability in all the implementations, not just MPICH and OMPI but the downstream derivatives that may implement it distinctly from what the OSS upstream projects are doing. I am not convinced that we need more than one implementation of any C++ interface to MPI. Do we expect closed-source vendor implementations? Is it likely that this interface will depend on proprietary internals of any implementation?

I contend that, for MPI C++ support, we are better off with the Linux model of having the open-source implementation be the specification. I am open to being convinced otherwise.

Jeff

On Tue, Jul 1, 2025 at 5:30 PM Wes Bland via mpi-forum <[email protected]> wrote:

...

Hi Tony, I’ll refer to the procedures doc here: https: //www. mpi-forum. org/docs/other/procedures-36. pdf (*pushes glasses up nose* - Section 2. 2. 5). For side documents, you’ll follow the same procedure as a regular proposal (have a plenary/reading ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd Hi Tony,

I’ll refer to the procedures doc here: https://urldefense.us/v3/__https://www.mpi-forum.org/docs/other/procedures-3... (*pushes glasses up nose* - Section 2.2.5).

For side documents, you’ll follow the same procedure as a regular proposal (have a plenary/reading first, then two votes). The only difference is that updates to side docs incrementing the minor version number only have to pass a single vote (like an errata).

Organizationally, we have repositories for each of the side documents in the main MPI Forum GitHub organization so it’s easier for folks to find them. You can find an example with the newer Memory Allocation Kinds side document here: https://urldefense.us/v3/__https://github.com/mpi-forum/mem-alloc__;!!G_uCfs.... I’d be happy to make a repo for you if you’re interested.

I'll put you on the list for the North Carolina meeting. I’m also happy to help schedule a non-voting meeting if you want to get some early feedback during one of our Wednesday time slots.

Thanks, Wes

On Jun 26, 2025, at 10:10 AM, Skjellum, Anthony via mpi-forum <[email protected]> wrote:

This Message Is From an External Sender This message came from outside your organization. Dear Wesley and Martin, how is a side document proposed to the forum?

We wish to prepare a side document.

Also, here is our recent EuroMPI paper describing the thinking and learning of the subcommittee on C++; we would also like to have a chance to share this at the SC25 BOF.

If we can have plenary time at the next meeting, that would be good. North Carolina, right?

Here is the EuroMPI paper from Arxiv:

https://urldefense.us/v3/__https://www.arxiv.org/abs/2506.14610__;!!G_uCfscf...

Thanks, Tony

Anthony Skjellum, PhD Professor of Computer Science Director, Advanced Scalable Computing, Extreme Networks & Data (ASCEND) Center Tennessee Technological University email: [email protected] cell: +1-205-807-4968

_______________________________________________ mpi-forum mailing list [email protected] https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi-...

_______________________________________________ mpi-forum mailing list [email protected] https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi-...

-- Jeff [email protected]https://urldefense.us/v3/__http://jeffhammond.github.io/__;!!G_uCfscf7eWS!Z8...

_______________________________________________ mpi-forum mailing list [email protected] https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi-...

-- Anthony Skjellum, PhD [email protected] Cell: +1-205-807-4968