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

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

27 Apr '25

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…>

1 0

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

27 Apr '25

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: > > > This Message Is From an External Sender > This message came from outside your organization. > 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…

1 0

Re: [mpiwg-languages] static datatypes lifetimes
by Joseph Schuchart 26 Apr '25

26 Apr '25

1 0

Re: [mpiwg-languages] static datatypes lifetimes
by Alfredo Correa 25 Apr '25

25 Apr '25

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 Ghosh, Sayan 25 Apr '25

25 Apr '25

Good point to raise, Alfredo. Tim – were you referring to this? * Delete callback associated with communicators gets called when communicator is freed * 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) -- 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!dDshRCeik… From: mpiwg-languages <mpiwg-languages-bounces(a)lists.mpi-forum.org> on behalf of Alfredo Correa via mpiwg-languages <mpiwg-languages(a)lists.mpi-forum.org> Date: Friday, April 25, 2025 at 1:45 PM To: mpiwg-languages(a)lists.mpi-forum.org <mpiwg-languages(a)lists.mpi-forum.org>, tim.uhl(a)kit.edu <tim.uhl(a)kit.edu> Cc: Alfredo Correa <alfredo.correa(a)gmail.com> Subject: [mpiwg-languages] static datatypes lifetimes Check twice before you click! This email originated from outside PNNL. Hi Tim, the other day you mention that you played with attaching datatypes (specifically static data types) as keyvalues. This is very interesting. The first thing I notice is that these datatypes will not be global, which is good. but it also ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi Tim, the other day you mention that you played with attaching datatypes (specifically static data types) as keyvalues. This is very interesting. The first thing I notice is that these datatypes will not be global, which is good. but it also means that they are attached to communicators, not the MPI environment. Am I correct? This would solve the problem of freeing datatypes on program exit. This is different from the idea of attaching it to environment that I was mentioning, but it is possible that attaching it to the communicator is actually a better idea. At the very least, because MPI has a mechanism to “attach” stuff to communicators, but not to the environment.

1 0

static datatypes lifetimes
by Alfredo Correa 25 Apr '25

25 Apr '25

Hi Tim, the other day you mention that you played with attaching datatypes (specifically static data types) as keyvalues. This is very interesting. The first thing I notice is that these datatypes will not be global, which is good. but it also means that they are attached to communicators, not the MPI environment. Am I correct? This would solve the problem of freeing datatypes on program exit. This is different from the idea of attaching it to environment that I was mentioning, but it is possible that attaching it to the communicator is actually a better idea. At the very least, because MPI has a mechanism to “attach” stuff to communicators, but not to the environment.

1 0

Re: [mpiwg-languages] Language WG agenda for the next weeks
by Uhl, Tim Niklas (ITI) 24 Apr '25

24 Apr '25

Hi Victor, The current meeting link is https://urldefense.us/v3/__https://tntech.zoom.us/j/86485761734?pwd=TGlMT0t… . The meeting will start at 10 am US central (5pm CET). 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 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 On 24. Apr 2025, at 15:03, Victor Eijkhout <eijkhout(a)tacc.utexas.edu> wrote: I must have an old zoom link. Remind me? V. <<

1 0

Re: [mpiwg-languages] Language WG agenda for the next weeks
by Victor Eijkhout 24 Apr '25

24 Apr '25

I must have an old zoom link. Remind me? V. <<

1 0

Language WG agenda for the next weeks
by Uhl, Tim Niklas (ITI) 22 Apr '25

22 Apr '25

1 0

Meeting 2025-03-06 cancelled
by Uhl, Tim Niklas (ITI) 06 Mar '25

06 Mar '25

1 0