- mpiwg-languages - mailman3.cels.anl.gov

Re: [mpiwg-languages] Talk on Error Handling and Exceptions by Aurelien Bouteiller
by Uhl, Tim Niklas (ITI) 27 Aug '25

27 Aug '25

And here is the abstract of the talk: Dancing around the lack of language support to deploy MPI Fault tolerance: MPI has long provided the concept of error handlers to capture errors during MPI operations in a less intrusive way than return code. This approach however lacks integration with high-level error management mechanisms provided by modern programming languages (e.g., exceptions), and consequently unwinding erroneous function frames remains complex for users. In this presentation we will describe state of the practice in MPI Fault tolerance coding patterns, and discuss how a tighter language integration could alleviate serious limitations in terms of code productivity and interoperability with runtimes. -- Karlsruhe Institute of Technology (KIT) Institute of Theoretical Informatics Algorithm Engineering Group Tim Niklas Uhl, M.Sc. Doctoral Researcher, PhD Candidate Am Fasanengarten 5, Room 221 Building 50.34 76131 Karlsruhe, Germany Phone: +49 721 608-43564 Fax: +49 721 608-43088 E-mail: uhl(a)kit.edu Web: https://urldefense.us/v3/__https://ae.iti.kit.edu/english/uhl.php__;!!G_uCf… Registered Office: Kaiserstraße 12, 76131 Karlsruhe, Germany KIT – The Research University in the Helmholtz Association On 27. Aug 2025, at 09:05, Uhl, Tim Niklas (ITI) via mpiwg-languages <mpiwg-languages(a)lists.mpi-forum.org> wrote: This Message Is From an External Sender This message came from outside your organization. Dear colleagues, In tomorrow’s working group meeting, Aurelien Bouteiller (University of Tennessee, Knoxville) will discuss error handling and exceptions. The meeting will take place as usual on Thursday at 10 a.m. US Central at [1]. Feel free to join. Best, Tim [1] https://urldefense.us/v3/__https://tntech.zoom.us/j/86485761734?pwd=TGlMT0t… -- Karlsruhe Institute of Technology (KIT) Institute of Theoretical Informatics Algorithm Engineering Group Tim Niklas Uhl, M.Sc. Doctoral Researcher, PhD Candidate Am Fasanengarten 5, Room 221 Building 50.34 76131 Karlsruhe, Germany Phone: +49 721 608-43564 Fax: +49 721 608-43088 E-mail: uhl(a)kit.edu<mailto:[email protected]> Web: https://urldefense.us/v3/__https://ae.iti.kit.edu/english/uhl.php__;!!G_uCf… Registered Office: Kaiserstraße 12, 76131 Karlsruhe, Germany KIT – The Research University in the Helmholtz Association -- mpiwg-languages mailing list mpiwg-languages(a)lists.mpi-forum.org<mailto:[email protected]> https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi…

1 0

Talk on Error Handling and Exceptions by Aurelien Bouteiller
by Uhl, Tim Niklas (ITI) 27 Aug '25

27 Aug '25

1 0

Re: [mpiwg-languages] [Today] Talk on Stream-Triggered Communication by Patrick Bridges
by Uhl, Tim Niklas (ITI) 21 Aug '25

21 Aug '25

And here is the meeting link [1] https://urldefense.us/v3/__https://tntech.zoom.us/j/86485761734?pwd=TGlMT0t… -- Karlsruhe Institute of Technology (KIT) Institute of Theoretical Informatics Algorithm Engineering Group Tim Niklas Uhl, M.Sc. Doctoral Researcher, PhD Candidate Am Fasanengarten 5, Room 221 Building 50.34 76131 Karlsruhe, Germany Phone: +49 721 608-43564 Fax: +49 721 608-43088 E-mail: uhl(a)kit.edu Web: https://urldefense.us/v3/__https://ae.iti.kit.edu/english/uhl.php__;!!G_uCf… Registered Office: Kaiserstraße 12, 76131 Karlsruhe, Germany KIT – The Research University in the Helmholtz Association On 21. Aug 2025, at 16:39, Uhl, Tim Niklas (ITI) via mpiwg-languages <mpiwg-languages(a)lists.mpi-forum.org> wrote: This Message Is From an External Sender This message came from outside your organization. Dear colleagues, Today’s working group meeting (9 a.m. US central at [1]) will feature Patrick Bridges (UNM), who will discuss Stream-Triggered Communication. Feel free to join the presentation and discussion. I apologize for the short notice. Best, Tim -- Karlsruher Institut für Technologie (KIT) Institut für Theoretische Informatik Lehrstuhl Algorithm Engineering Tim Niklas Uhl, M.Sc. Wissenschaftlicher Mitarbeiter Am Fasanengarten 5, Raum 221 Gebäude 50.34 76131 Karlsruhe Telefon: +49 721 608-45270 Fax: +49 721 608-43088 E-Mail: uhl(a)kit.edu<mailto:[email protected]> Web: https://urldefense.us/v3/__https://ae.iti.kit.edu/uhl.php__;!!G_uCfscf7eWS!… Sitz der Körperschaft: Kaiserstraße 12, 76131 Karlsruhe KIT – Die Forschungsuniversität in der Helmholtz-Gemeinschaft -- mpiwg-languages mailing list mpiwg-languages(a)lists.mpi-forum.org<mailto:[email protected]> https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi…

1 0

[Today] Talk on Stream-Triggered Communication by Patrick Bridges
by Uhl, Tim Niklas (ITI) 21 Aug '25

21 Aug '25

1 0

next WG meeting June 26; agenda: one-sided
by Uhl, Tim Niklas (ITI) 17 Jun '25

17 Jun '25

1 0

Meeting canceled for today.
by Skjellum, Anthony 01 May '25

01 May '25

All: Lots of conflicts, and holiday in Germany. _Tony Anthony Skjellum, PhD Professor of Computer Science Director, Advanced Scalable Computing, Extreme Networks & Data (ASCEND) Center Tennessee Technological University email: askjellum(a)tntech.edu cell: +1-205-807-4968

1 0

Re: [mpiwg-languages] static datatypes lifetimes
by Ghosh, Sayan 27 Apr '25

27 Apr '25

Thoughts on session ErrorHandler for releasing datatypes? From this diagram (in section 9.3), it seems the prevailing thought is to use session callbacks just like communicator callbacks. [cid:[email protected]] -- 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!bYfNlyALF… From: mpiwg-languages <mpiwg-languages-bounces(a)lists.mpi-forum.org> on behalf of Joseph Schuchart via mpiwg-languages <mpiwg-languages(a)lists.mpi-forum.org> Date: Saturday, April 26, 2025 at 7:51 PM To: mpiwg-languages(a)lists.mpi-forum.org <mpiwg-languages(a)lists.mpi-forum.org> Cc: Joseph Schuchart <joseph.schuchart(a)stonybrook.edu> Subject: Re: [mpiwg-languages] static datatypes lifetimes Check twice before you click! This email originated from outside PNNL. 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(a)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 > _ > _ > >

1 0

Re: [mpiwg-languages] static datatypes lifetimes
by Jeff Hammond 27 Apr '25

27 Apr '25

On Sun, Apr 27, 2025 at 7:04 PM Skjellum, Anthony <askjellum(a)tntech.edu> wrote: > 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? > If somebody wants to do this, they can implement it on a per call site inside of the MPI library by running a short backtrace to identify the call site and selecting an algorithm for that call site based on a profile database. On the other hand, nobody cares if it's MPI or not when the standard API of interest to AI is pytorch.distributed. > 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 would pay money for you and Jasper to have a public debate about adding versus subtracting features from MPI ;-) https://urldefense.us/v3/__https://github.com/mpi-forum/mpi-issues/issues/9… > 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. > No, I don't care about orthogonality and I don't prioritize peak performance. If we want orthogonality, we should have put, put-with-notify, wait and test, and implement everything else in terms of those. We are so far from orthogonality and it's fine. We have 5+ kinds of send. We can implement alltoall with scatter or with send-recv or with win_create+fence+put, etc. etc. The MPI standard has so much linear dependency and that's actually fine, because it's solving the problems that our users have. See the following comment about peak performance... > Right now, MPI is slower than vendor-specific primitives, limiting its use > on key applications. That also drives my thinking. > And this has always been true. It was true on Blue Gene, yet only the QCD folks wrote in anything but MPI. I regularly gave workshop talks about the merits of DCMF and PAMI, but nobody used them for anything except implementing GASNet and Charm++. I don't think peak performance is feasible for MPI and don't think it's a useful goal for the Forum. What we want is time- and system-averaged performance over all the HPC architectures across decades. > 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. > Yes, allowing expert users to select the algorithm for each call site will show upside in some cases. On the other hand, it will ruin the performance portability of MPI apps, because the best collective algorithm is machine-dependent. At that point, you should just write non-portable code, e.g. UCC. Heck, selecting the best algorithm is not even performance portable across different versions of an MPI library on the same system. jeff > Tony > > > Anthony Skjellum, PhD > Professor of Computer Science > Director, Advanced Scalable Computing, > Extreme Networks & Data (ASCEND) Center > Tennessee Technological University > email: askjellum(a)tntech.edu > cell: +1-205-807-4968 > > > ------------------------------ > *From:* Jeff Hammond <jeff.science(a)gmail.com> > *Sent:* Sunday, April 27, 2025 8:33 AM > *To:* Skjellum, Anthony <askjellum(a)tntech.edu> > *Cc:* mpiwg-languages(a)lists.mpi-forum.org < > mpiwg-languages(a)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(a)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(a)tntech.edu > cell: +1-205-807-4968 > > > ------------------------------ > *From:* mpiwg-languages <mpiwg-languages-bounces(a)lists.mpi-forum.org> on > behalf of Jeff Hammond via mpiwg-languages < > mpiwg-languages(a)lists.mpi-forum.org> > *Sent:* Saturday, April 26, 2025 11:53 PM > *To:* mpiwg-languages(a)lists.mpi-forum.org < > mpiwg-languages(a)lists.mpi-forum.org> > *Cc:* Jeff Hammond <jeff.science(a)gmail.com>; > mpiwg-languages(a)lists.mpi-forum.org <mpiwg-languages(a)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(a)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(a)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(a)lists.mpi-forum.org > https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi… > <https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi…> > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > https://urldefense.us/v3/__http://jeffhammond.github.io/__;!!G_uCfscf7eWS!a… > -- Jeff Hammond jeff.science(a)gmail.com https://urldefense.us/v3/__http://jeffhammond.github.io/__;!!G_uCfscf7eWS!a…

1 0

Re: [mpiwg-languages] static datatypes lifetimes
by Skjellum, Anthony 27 Apr '25

27 Apr '25

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(a)tntech.edu cell: +1-205-807-4968 ________________________________ From: Jeff Hammond <jeff.science(a)gmail.com> Sent: Sunday, April 27, 2025 8:33 AM To: Skjellum, Anthony <askjellum(a)tntech.edu> Cc: mpiwg-languages(a)lists.mpi-forum.org <mpiwg-languages(a)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(a)tntech.edu<mailto:[email protected]>> 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(a)tntech.edu<mailto:[email protected]> cell: +1-205-807-4968 ________________________________ From: mpiwg-languages <mpiwg-languages-bounces(a)lists.mpi-forum.org<mailto:[email protected]>> on behalf of Jeff Hammond via mpiwg-languages <mpiwg-languages(a)lists.mpi-forum.org<mailto:[email protected]>> Sent: Saturday, April 26, 2025 11:53 PM To: mpiwg-languages(a)lists.mpi-forum.org<mailto:[email protected]> <mpiwg-languages(a)lists.mpi-forum.org<mailto:[email protected]>> Cc: Jeff Hammond <jeff.science(a)gmail.com<mailto:[email protected]>>; mpiwg-languages(a)lists.mpi-forum.org<mailto:[email protected]> <mpiwg-languages(a)lists.mpi-forum.org<mailto:[email protected]>> 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(a)lists.mpi-forum.org<mailto:[email protected]>> 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(a)pnnl.gov<mailto:[email protected]>> 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(a)lists.mpi-forum.org<mailto:[email protected]> https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi… <https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi…> -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> https://urldefense.us/v3/__http://jeffhammond.github.io/__;!!G_uCfscf7eWS!Y…

1 0

Re: [mpiwg-languages] static datatypes lifetimes
by Jeff Hammond 27 Apr '25

27 Apr '25

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(a)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(a)tntech.edu > cell: +1-205-807-4968 > > > ------------------------------ > *From:* mpiwg-languages <mpiwg-languages-bounces(a)lists.mpi-forum.org> on > behalf of Jeff Hammond via mpiwg-languages < > mpiwg-languages(a)lists.mpi-forum.org> > *Sent:* Saturday, April 26, 2025 11:53 PM > *To:* mpiwg-languages(a)lists.mpi-forum.org < > mpiwg-languages(a)lists.mpi-forum.org> > *Cc:* Jeff Hammond <jeff.science(a)gmail.com>; > mpiwg-languages(a)lists.mpi-forum.org <mpiwg-languages(a)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(a)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(a)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(a)lists.mpi-forum.org > https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi… > <https://urldefense.us/v3/__https://lists.mpi-forum.org/mailman/listinfo/mpi…> > > -- Jeff Hammond jeff.science(a)gmail.com https://urldefense.us/v3/__http://jeffhammond.github.io/__;!!G_uCfscf7eWS!d…

1 0