[mpiwg-hybridpm] Meeting for June 12, 2024

Skjellum, Anthony askjellum at tntech.edu
Fri Jun 7 08:03:34 CDT 2024


Dan, it is good to hear from you.  !!!!

Let's do a virtual coffee soon.

I am always interested in the multivendor solution---on that matter we should talk.

I do have staff (recent students) working on the experimental systems with various proposals for kernel and stream-triggered communication, for which we think Pbuf_prepare is of value to manage a) the unexpected message situation, b) forcing the initial matching.   Patrick added some notes.  We are all trying in the next year of our DOE center to advance concepts that we can try to put into the standard.  They have to improve performance and predictability to make the cut, IMHO.

We have to make all these experimental systems work.  We would like to see what Intel is offering along these lines.

We have a nearly complete survey paper to be shareable (sharable?) soon.  It surveys eight API families for kernel and stream triggered, but Intel not represented in what we have studied as of now.

May we know the Intel approach to stream and or kernel triggered comms?  Is it through the MPICH extensions we are studying?

We recognize that Parrived_any is a weaker requirement on the channel, allowing work to be processed as it arrives.  Could also by handled with a wildcard in the Parrived.
Application programmerrs say this is what is reflective of the load-imbalanced arrival.

Australia is too far away for me too, and too expensive too.  And seems like a bad venue to get people to go.  I'd like to go there on a month's vacation someday, not for 4 days half-way around the globe or such.

I wish for help on the response to the Argonne progress for all paper, should you be at liberty to give opinions.  If not allowable to be a co-author, I still would value guidance and input.

Quick response, hope coherent.

Tony


Anthony Skjellum, PhD
Professor of Computer Science
Tennessee Technological University
email: askjellum at tntech.edu
cell: +1-205-807-4968


________________________________
From: mpiwg-hybridpm <mpiwg-hybridpm-bounces at lists.mpi-forum.org> on behalf of Skjellum, Anthony via mpiwg-hybridpm <mpiwg-hybridpm at lists.mpi-forum.org>
Sent: Wednesday, June 5, 2024 9:31 AM
To: mpiwg-hybridpm at lists.mpi-forum.org <mpiwg-hybridpm at lists.mpi-forum.org>
Cc: Skjellum, Anthony <askjellum at tntech.edu>; Patrick Bridges <patrickb at unm.edu>; Ryan Eric Grant <reg1 at queensu.ca>; Purushotham Bangalore <pvbangalore at ua.edu>
Subject: [mpiwg-hybridpm] Meeting for June 12, 2024


External Email Warning

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

________________________________
Jim, and others, I would like to discuss these topics (frozen proposals from MPI-4 and 4. 1) at the next meeting on June 12: Pbuf_prepare, Parrived_any I would like to see if we can get agreement on these and push into MPI-4. 2 or the next increment
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd
Jim, and others, I would like to discuss these topics (frozen proposals from MPI-4 and 4.1) at the next meeting on June 12:

Pbuf_prepare, Parrived_any

I would like to see if we can get agreement on these and push into MPI-4.2 or the next increment after that, rather than MPI-5.
I am sure this will take more than one discussion, since we didn't get these through before.

Note: They are both marked for MPI-5 currently, presumably because we don't have a broad opening for MPI-4.2, and we haven't agreed on an MPI-4.3.


Here are the tickets/issues:

https://urldefense.us/v3/__https://github.com/mpi-forum/mpi-issues/issues/537__;!!G_uCfscf7eWS!dUPH4_vC66p2DkETqQkJ7UzFCkmH2SoXYNdcuEfcJPf89ShybGO4xq7BkqbVfHtpIZv4GOOFxnNnCsh9u_KZHzBRm4rklS7k_tqY$ <https://urldefense.us/v3/__https://github.com/mpi-forum/mpi-issues/issues/537__;!!G_uCfscf7eWS!ZyZVjdWV6k41axZ3KnxwyMryXZZVlkJeaQidg7_lF3bDw-Fk2VzEaU_IcX7dZ5Cv8ZqLwEhN8CC1BqwKhKj1hFpCxBMDLcELRBJq$> (PR:https://urldefense.us/v3/__https://github.com/mpi-forum/mpi-standard/pull/718__;!!G_uCfscf7eWS!dUPH4_vC66p2DkETqQkJ7UzFCkmH2SoXYNdcuEfcJPf89ShybGO4xq7BkqbVfHtpIZv4GOOFxnNnCsh9u_KZHzBRm4rklT3mO5S2$ <https://urldefense.us/v3/__https://github.com/mpi-forum/mpi-standard/pull/718__;!!G_uCfscf7eWS!ZyZVjdWV6k41axZ3KnxwyMryXZZVlkJeaQidg7_lF3bDw-Fk2VzEaU_IcX7dZ5Cv8ZqLwEhN8CC1BqwKhKj1hFpCxBMDLYShSrSD$> ) – Ryan prepared the PR long ago.
[https://urldefense.us/v3/__https://opengraph.githubassets.com/6ac106e7db39c1db8f8d04107bddc2cd8f9e0b93935e59eb57244db11af8290a/mpi-forum/mpi-issues/issues/537__;!!G_uCfscf7eWS!dUPH4_vC66p2DkETqQkJ7UzFCkmH2SoXYNdcuEfcJPf89ShybGO4xq7BkqbVfHtpIZv4GOOFxnNnCsh9u_KZHzBRm4rkla46EVrS$ ]<https://urldefense.us/v3/__https://github.com/mpi-forum/mpi-issues/issues/537__;!!G_uCfscf7eWS!ZyZVjdWV6k41axZ3KnxwyMryXZZVlkJeaQidg7_lF3bDw-Fk2VzEaU_IcX7dZ5Cv8ZqLwEhN8CC1BqwKhKj1hFpCxBMDLcELRBJq$>
MPI_Parrived_any API as an addition for Partititioned Communication · Issue #537 · mpi-forum/mpi-issues<https://urldefense.us/v3/__https://github.com/mpi-forum/mpi-issues/issues/537__;!!G_uCfscf7eWS!ZyZVjdWV6k41axZ3KnxwyMryXZZVlkJeaQidg7_lF3bDw-Fk2VzEaU_IcX7dZ5Cv8ZqLwEhN8CC1BqwKhKj1hFpCxBMDLcELRBJq$>
Problem The ability to take the next available partition is not supported in the current MPI-4.0 API. Proposal The API: MPI_Parrived_any(MPI_Request prequest, int *partition, int *flag); /* C inter...
github.com



https://urldefense.us/v3/__https://github.com/mpi-forum/mpi-issues/issues/302__;!!G_uCfscf7eWS!dUPH4_vC66p2DkETqQkJ7UzFCkmH2SoXYNdcuEfcJPf89ShybGO4xq7BkqbVfHtpIZv4GOOFxnNnCsh9u_KZHzBRm4rklXX-8-WL$ <https://urldefense.us/v3/__https://github.com/mpi-forum/mpi-issues/issues/302__;!!G_uCfscf7eWS!ZyZVjdWV6k41axZ3KnxwyMryXZZVlkJeaQidg7_lF3bDw-Fk2VzEaU_IcX7dZ5Cv8ZqLwEhN8CC1BqwKhKj1hFpCxBMDLUxIuITZ$>  (with outdated PR:  https://urldefense.us/v3/__https://github.com/mpi-forum/mpi-standard/pull/264__;!!G_uCfscf7eWS!dUPH4_vC66p2DkETqQkJ7UzFCkmH2SoXYNdcuEfcJPf89ShybGO4xq7BkqbVfHtpIZv4GOOFxnNnCsh9u_KZHzBRm4rklQ18dwIp$ <https://urldefense.us/v3/__https://github.com/mpi-forum/mpi-standard/pull/264__;!!G_uCfscf7eWS!ZyZVjdWV6k41axZ3KnxwyMryXZZVlkJeaQidg7_lF3bDw-Fk2VzEaU_IcX7dZ5Cv8ZqLwEhN8CC1BqwKhKj1hFpCxBMDLXOQpejn$>  ) – Ryan prepared the PR long ago.


My apologies for long delays in follow up.  We really need to resolve these issues as they impact both point-to-point partitioned and potential collective partitioned comms.

I would encourage additional commentary on the issues; Patrick has made new, relevant observations about the dual roles of Pbuf_prepare recently on ticket#302, for example.

Thank you all,
Tony

PS After that, I really do intend to hold a collective WG meeting to discuss partitioned collective ops 🙂 on June 19, or July 3 or 10, depending
what works in tandem with the Hybrid calendar.


Anthony Skjellum, PhD
Professor of Computer Science
Tennessee Technological University
email: askjellum at tntech.edu
cell: +1-205-807-4968


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20240607/4aa1dad9/attachment-0001.html>


More information about the mpiwg-hybridpm mailing list