[Mpi-forum] Proposal process for a side document for C++ Language Interface for MPI-5.x

Fri Sep 12 13:34:43 CDT 2025

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 <
mpi-forum at lists.mpi-forum.org> 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!ajr8hPuv5sdt9qjfCwDmAeYnmP_EYcqymJaju91ri-j9tW72jDOu86oT90_Eo5cNuPVRC4mLktpjBph-6eU7aFPTlg$ 
> <https://urldefense.us/v3/__https://sg0.github.io/__;!!G_uCfscf7eWS!c9LeMozG_yZM54PFqHqEeSabOx1D-x2QdhfuSPa30JtEl5Cm8QDaniu-dxQy9rQZM_FMJp5AiwMd82gVb70IOBqdpTsxb2X6$>*
>
>
> *From: *mpi-forum <mpi-forum-bounces at lists.mpi-forum.org> on behalf of
> Jeff Hammond via mpi-forum <mpi-forum at lists.mpi-forum.org>
> *Date: *Friday, September 12, 2025 at 1:16 AM
> *To: *Wes Bland <work at wesbland.com>
> *Cc: *MPI Forum <mpi-forum at lists.mpi-forum.org>, Suggs, Evan <
> esuggs at tntech.edu>, Uhl, Tim Niklas (SCC) <tim.uhl at kit.edu>, Matthias
> Schimek <matthias.schimek at kit.edu>
> *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
> <mpi-forum at lists.mpi-forum.org> 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-36.pdf__;!!G_uCfscf7eWS!Z8jqX_bSy2iiaUh4QR-DabaxiRq5JX6mQXKa_9bV0gLTIIUb6Zhhn0hKzbWk65k9ZddzodXLa2yH_heA5DJk3ztaZ0gVGuA$ (*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_uCfscf7eWS!Z8jqX_bSy2iiaUh4QR-DabaxiRq5JX6mQXKa_9bV0gLTIIUb6Zhhn0hKzbWk65k9ZddzodXLa2yH_heA5DJk3ztaWwKnoOY$. 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 <mpi-forum at lists.mpi-forum.org> 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_uCfscf7eWS!Z8jqX_bSy2iiaUh4QR-DabaxiRq5JX6mQXKa_9bV0gLTIIUb6Zhhn0hKzbWk65k9ZddzodXLa2yH_heA5DJk3ztaJkPlS40$
> >
> >
> > Thanks,
> > Tony
> >
> >
> > Anthony Skjellum, PhD
> > Professor of Computer Science
> > Director, Advanced Scalable Computing,
> >               Extreme Networks & Data (ASCEND) Center
> > Tennessee Technological University
> > email: askjellum at tntech.edu
> > cell: +1-205-807-4968
> >
> >
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org
> > https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi-forum__;!!G_uCfscf7eWS!Z8jqX_bSy2iiaUh4QR-DabaxiRq5JX6mQXKa_9bV0gLTIIUb6Zhhn0hKzbWk65k9ZddzodXLa2yH_heA5DJk3ztaq6sMe7U$
> >
> >
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org
> > https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi-forum__;!!G_uCfscf7eWS!Z8jqX_bSy2iiaUh4QR-DabaxiRq5JX6mQXKa_9bV0gLTIIUb6Zhhn0hKzbWk65k9ZddzodXLa2yH_heA5DJk3ztaq6sMe7U$
>
>
>
> --
> Jeff Hammondjeff.science at gmail.comhttps://urldefense.us/v3/__http://jeffhammond.github.io/__;!!G_uCfscf7eWS!Z8jqX_bSy2iiaUh4QR-DabaxiRq5JX6mQXKa_9bV0gLTIIUb6Zhhn0hKzbWk65k9ZddzodXLa2yH_heA5DJk3ztaXFqrcRk$
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi-forum__;!!G_uCfscf7eWS!ajr8hPuv5sdt9qjfCwDmAeYnmP_EYcqymJaju91ri-j9tW72jDOu86oT90_Eo5cNuPVRC4mLktpjBph-6eW1l6Eaaw$ 
>

-- 
Anthony Skjellum, PhD
skjellum at gmail.com
Cell: +1-205-807-4968
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20250912/4a3dabc1/attachment-0001.html>