[mpiwg-languages] static datatypes lifetimes

Sun Apr 27 11:03:58 CDT 2025

Jeff, thank you, I will read more about UCC.

In the meantime, since I like MPI a lot, and intend to keep using it, and trying to make it better, I mentioned this because I view MPI_Info arguments is a substitute for polymorphism in the interface, as I know you know, and with AI/machine-learning, we might be able to generate wisdom/profile-guided optimization to fulfill these arguments.  Is this not a good direction?

And, since you probably know that I've brought up orthogonality of the APIs before many times in the meetings, I am worried that we have not made the more general operations like non-blocking have the ability to give assertions or info.

I am mostly interested in more performance in MPI, that's why I added my comment to yours.  Do you think it is not a good idea to orthogonalize to support optimization, or is there a better way to achieve higher performance in your opinion.

Right now, MPI is slower than vendor-specific primitives, limiting its use on key applications.  That also drives my thinking.

The use case I am thinking of is improved choice of algorithm, for collectives.  Or knowing that buffers have specific semantics without the cost of testing.

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

________________________________
From: Jeff Hammond <jeff.science at gmail.com>
Sent: Sunday, April 27, 2025 8:33 AM
To: Skjellum, Anthony <askjellum at tntech.edu>
Cc: mpiwg-languages at lists.mpi-forum.org <mpiwg-languages at lists.mpi-forum.org>
Subject: Re: [mpiwg-languages] static datatypes lifetimes

External Email Warning

This email originated from outside the university. Please use caution when opening attachments, clicking links, or responding to requests.

________________________________
I think the API you want then is basically UCC.  Prescribe everything for every operation.

Jeff

On Sun, Apr 27, 2025 at 6:10 PM Skjellum, Anthony <askjellum at tntech.edu<mailto:askjellum at tntech.edu>> wrote:
Another issue: Info arguments are missing on non-blocking and blocking collectives.

Anthony Skjellum, PhD
Professor of Computer Science
Director, Advanced Scalable Computing,
              Extreme Networks & Data (ASCEND) Center
Tennessee Technological University
email: askjellum at tntech.edu<mailto:askjellum at tntech.edu>
cell: +1-205-807-4968

________________________________
From: mpiwg-languages <mpiwg-languages-bounces at lists.mpi-forum.org<mailto:mpiwg-languages-bounces at lists.mpi-forum.org>> on behalf of Jeff Hammond via mpiwg-languages <mpiwg-languages at lists.mpi-forum.org<mailto:mpiwg-languages at lists.mpi-forum.org>>
Sent: Saturday, April 26, 2025 11:53 PM
To: mpiwg-languages at lists.mpi-forum.org<mailto:mpiwg-languages at lists.mpi-forum.org> <mpiwg-languages at lists.mpi-forum.org<mailto:mpiwg-languages at lists.mpi-forum.org>>
Cc: Jeff Hammond <jeff.science at gmail.com<mailto:jeff.science at gmail.com>>; mpiwg-languages at lists.mpi-forum.org<mailto:mpiwg-languages at lists.mpi-forum.org> <mpiwg-languages at lists.mpi-forum.org<mailto:mpiwg-languages at lists.mpi-forum.org>>
Subject: Re: [mpiwg-languages] static datatypes lifetimes

External Email Warning

This email originated from outside the university. Please use caution when opening attachments, clicking links, or responding to requests.

________________________________
Attributes on ops, datatypes and files is critical for multiple use cases. It’s ridiculous we don’t have them. The standard is inconsistent without. Jeff Sent from my iPhone On 27. Apr 2025, at 5. 51, Joseph Schuchart via mpiwg-languages <mpiwg-languages@ lists. mpi-forum. org>
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd
Attributes on ops, datatypes and files is critical for multiple use cases. It’s ridiculous we don’t have them. The standard is inconsistent without.

Jeff

Sent from my iPhone

On 27. Apr 2025, at 5.51, Joseph Schuchart via mpiwg-languages <mpiwg-languages at lists.mpi-forum.org<mailto:mpiwg-languages at lists.mpi-forum.org>> wrote:

Unfortunately, there is a catch: MPI_COMM_SELF is only relevant/available/valid in the World Process Model (WPM), i. e. , if using `MPI_Init`/`MPI_Finalize`. In the Sessions process model, predefined communicators are not available. The life-time
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Unfortunately, there is a catch: MPI_COMM_SELF is only
relevant/available/valid in the World Process Model (WPM), i.e., if
using `MPI_Init`/`MPI_Finalize`. In the Sessions process model,
predefined communicators are not available.

The life-time of datatypes is a known quirk and I think it was
discovered after Sessions became part of the standard. They are not
bound to any other MPI object and can survive complete shutdown of all
sessions / the WPM. IIRC in Open MPI (but have to check), datatypes
retain a reference on the internal MPI instance and it is the
application's responsibility to free all MPI objects before shutdown.
Once the last datatype/session/wpm is gone we release the instance.

I don't like the state of things there and it is problematic. For
starters, it prevents complete session isolation (and the benefits that
come with it, such as different threading levels). It's not clear to me
how that can be rectified and I think the Forum is not clear on that
either, which is why we ended up with this weird zombie state. If
someone wants to open a ticket to start a discussion on this I'm happy
to participate.

For the problem at hand though (as I understand it), maybe it's
sufficient to add attributes to datatypes? I don't see why that would be
a problem and if it helps with language adoption we have a good argument
for it.

Cheers
Joseph

On 4/25/25 17:24, Alfredo Correa via mpiwg-languages wrote:
> Hi Sayan, On Fri, Apr 25, 2025 at 2: 03 PM Ghosh, Sayan
> <sayan. ghosh@ pnnl. gov> wrote: Consider finalize-delete-callback
> (this is what Alfredo is alluding to perhaps w. r. t
> datatype-attached-to-environment) – that seems to rely on MPI_COMM_SELF
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
> This message came from outside your organization.
> ZjQcmQRYFpfptBannerEnd
> Hi Sayan,
>
> On Fri, Apr 25, 2025 at 2:03 PM Ghosh, Sayan <sayan.ghosh at pnnl.gov<mailto:sayan.ghosh at pnnl.gov>> wrote:
>
>       * Consider finalize-delete-callback (this is what Alfredo is
>         alluding to perhaps w.r.t datatype-attached-to-environment) –
>         that seems to rely on MPI_COMM_SELF callback (freeing
>         comm-self triggers callback)
>
>
>
> That is a good point. At first glance, attaching things to
> MPI_COMM_WORLD or MPI_COMM_SELF would have a similar effect to
> attaching stuff to the environment.
> I didn't think about this because I was reluctant to modify (in any
> way) either of these special communicators, in particular MPI_COMM_WORLD.
> But MPI_COMM_SELF might still be a good candidate; others can point
> out if there is a catch.
>
> Thanks,
> Alfredo
> _
> _
>
>

--
mpiwg-languages mailing list
mpiwg-languages at lists.mpi-forum.org<mailto:mpiwg-languages at lists.mpi-forum.org>
https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpiwg-languages__;!!G_uCfscf7eWS!YU5C4R_45F3WBolF6NrVO09B9dDt1owLLjxjPYKSyUkobZODDHmw_OHlNHEySZ63tiQTfipO_xMReiTKzJlDNjHouP1VFzrwI3ka$ <https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpiwg-languages__;!!G_uCfscf7eWS!ZuNmK6mbS8qplL9AjJRWQ3PTAbAGMusqRU86UgvAro-oRcRR3IP5L-WaNZYOuqTljFttBrcvO2SBSSC6N1BMLIOoHQbouh28UsDH$>

--
Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
https://urldefense.us/v3/__http://jeffhammond.github.io/__;!!G_uCfscf7eWS!YU5C4R_45F3WBolF6NrVO09B9dDt1owLLjxjPYKSyUkobZODDHmw_OHlNHEySZ63tiQTfipO_xMReiTKzJlDNjHouP1VF-52izdE$ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-languages/attachments/20250427/d82871c1/attachment-0001.html>