January 2023 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] why do we only support caching on win/comm/datatype?
by Holmes, Daniel John 16 Jan '23

16 Jan '23

Hi Jeff, When adding session as an object to MPI, a deliberate choice was made not to support attributes for session objects because “attributes in MPI suck”. This decision was made despite the usage (by some tools) of “at exit” attribute callbacks fired by the destruction of MPI_COMM_SELF during MPI_FINALIZE in the world model and the consequent obvious omission of a similar hook during MPI_SESSION_FINALIZE in the session model (there is also no MPI_COMM_SELF in the session model, so this is not a simple subject). Removal of attributes entirely – blocked by back-compat because usage is known to exist. Expansion of attributes orthogonally – blocked by “attributes in MPI suck” accusations. Result – inconsistency in the interface that no-one wants to tackle. Best wishes, Dan. From: mpi-forum <mpi-forum-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond via mpi-forum Sent: 16 January 2023 14:40 To: MPI Forum <mpi-forum(a)lists.mpi-forum.org> Cc: Jeff Hammond <jeff.science(a)gmail.com> Subject: [Mpi-forum] why do we only support caching on win/comm/datatype? I am curious if there is a good reason from the past as to why we only support caching on win, comm and datatype, and no other handles? I have a good use case for request attributes and have found that the implementation overhead in MPICH appears to be zero. The implementation in MPICH requires adding a single pointer to an internal struct. This struct member will never be accessed except when the user needs it, and it can be placed at the end of the struct so that it doesn't even pollute the cache. I wondered if callbacks were a hidden overhead, but they only called explicitly and synchronously, so they would not interfere with critical path uses of requests. https://github.com/mpi-forum/mpi-issues/issues/664 has some details but since I do not understand how MPICH generates the MPI bindings, I only implemented the back-end MPIR code. It would make MPI more consistent if all opaque handles supported attributes. In particular, I'd love to have a built-in MPI_Op attribute for the function pointer the user provided (which is similar to how one can query input args associated with MPI_Win) because that appears to be the only way I can implement certain corner cases of MPI F08. Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/

1 0

why do we only support caching on win/comm/datatype?
by Jeff Hammond 16 Jan '23

16 Jan '23

I am curious if there is a good reason from the past as to why we only support caching on win, comm and datatype, and no other handles? I have a good use case for request attributes and have found that the implementation overhead in MPICH appears to be zero. The implementation in MPICH requires adding a single pointer to an internal struct. This struct member will never be accessed except when the user needs it, and it can be placed at the end of the struct so that it doesn't even pollute the cache. I wondered if callbacks were a hidden overhead, but they only called explicitly and synchronously, so they would not interfere with critical path uses of requests. https://github.com/mpi-forum/mpi-issues/issues/664 has some details but since I do not understand how MPICH generates the MPI bindings, I only implemented the back-end MPIR code. It would make MPI more consistent if all opaque handles supported attributes. In particular, I'd love to have a built-in MPI_Op attribute for the function pointer the user provided (which is similar to how one can query input args associated with MPI_Win) because that appears to be the only way I can implement certain corner cases of MPI F08. Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Readings announcements for the March meeting of the MPI Forum
by Guillaume Mercier 16 Jan '23

16 Jan '23

Dear all, The Topologies working Group would like to make the following readings: 1- Deprecate MPI_HOST Issue : https://github.com/mpi-forum/mpi-issues/issues/57 PR : https://github.com/mpi-forum/mpi-standard/pull/790 2- New interface to query hardware resource info Issue: https://github.com/mpi-forum/mpi-issues/issues/154 PR: https://github.com/mpi-forum/mpi-standard/pull/762 Regards Guillaume

1 0

Process management related reading for upcoming virtual voting Forum
by Pritchard Jr., Howard 13 Jan '23

13 Jan '23

Hi All, I’d like to put a second first (or maybe a no-no plus second) reading of Issue #514 Process management chapter changes for 4.1 - https://github.com/mpi-forum/mpi-issues/issues/514<https://urldefense.com/v3/__https:/github.com/mpi-forum/mpi-issues/issues/5…> PR #617 Topic/dynamic items deferred to 41 - https://github.com/mpi-forum/mpi-standard/pull/617<https://urldefense.com/v3/__https:/github.com/mpi-forum/mpi-standard/pull/6…> on the agenda for the Feb. 1/8 virtual forum. Thanks, Howard — [signature_61897647] Howard Pritchard Research Scientist HPC-ENV Los Alamos National Laboratory howardp(a)lanl.gov [signature_2019058760]<https://www.instagram.com/losalamosnatlab/>[signature_294581065]<https://twitter.com/LosAlamosNatLab>[signature_2736012172]<https://www.linkedin.com/company/los-alamos-national-laboratory/>[signature_2295225983]<https://www.facebook.com/LosAlamosNationalLab/>

1 0

Votes at MPI-Forum meeting Feb 1+8, 2023 (related to Terms and Topologies)
by Rolf Rabenseifner 12 Jan '23

12 Jan '23

Dear MPI forum members, dear Wesley, I would like to have the following issues (and their PRs) voted. They all had reading (or remembering reading) at the Dec. 2022 meeting. ================ Updating Side Document Function Table (SDFT) ============== 1st vote SDFT-17 SDFT - RMA section in Annex A.2 to be added Rolf 1st vote SDFT-5 SDFT - MPI_Comm_set_info is missing from function table Rolf 1st vote SDFT-7 SDFT - Why are MPI_COMM_CREATE, MPI_COMM_DUP etc not freeing? Rolf 1st vote SDFT-8 SDFT - Superfluous remark 4 on process topology functions Rolf 1st vote SDFT-10 SDFT - Handle special case of MPI_WAIT on a cancelled request Rolf 1st vote SDFT-11 SDFT - The column Procedure should be "Procedure Call" Rolf ================== 1st votes related to MPI 4.1 ============== 1st vote 641 Including Annex A.2 back into the standard Rolf 1st vote 493 Issue N - Progress-Section in terms-2.tex Rolf 1st vote 471 Fix Incorrect Usage of Rank/Task/etc. in Terms Chapter Rolf 1st vote 565 Refer to Fortran 2018 instead of 2008+TS Rolf+Jeff H. 1st vote 644 Update 'Process Topology' chapter title to use 'MPI process' Christoph ================== 2nd votes related to MPI 4.1 ============== 2nd vote 468 Issue K - MPI_REQUEST_GET_STATUS with same progress as MPI_TEST Rolf @Wesley, I already updated the milestone to Feb 2023. After this email, I'll update the flag from "Scheduled reading" to "scheduled vote". ================== 1st votes related to MPI 4.1 ================= == only if it will not be handled as a chapter committee change == == current status: chapter committee voting is done and on the way to the merge == 1st vote 649 Topology - use of MPI process where necessary Christoph 1st vote 650 Topology improvement around the term virtual topology Christoph 1st vote 651 Topology typos and smaller text improvements Christoph ================== Voted but still to be merged =============== == If there is another vote needed, then this is hereby also announced: == errata-voted 589 Issues with Partitioned Communication Example-4.4 (reread with No No) Christoph Best regards Rolf -- Dr. Rolf Rabenseifner . . . . . . . . . .. . . rabenseifner(a)hlrs.de . High Performance Computing Center (HLRS) . . . ++49(0)711/685-65530 . University of Stuttgart . . . . . . www.hlrs.de/people/rabenseifner . Nobelstr. 19, 70569 Stuttgart, Germany

1 0

Re: [Mpi-forum] February 2023 Meeting Registration
by Wes Bland 11 Jan '23

11 Jan '23

Another correction…sorry… The announcement deadline for the February meeting is January 18th, not March 18th. Also, the September meeting will be in Bristol, UK, not Briston, UK. I’m sure Briston is lovely, but as Dan pointed out, will be a long commute to the conference. > On Jan 11, 2023, at 10:25 AM, Wes Bland via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > Quick correction. The meeting times will be from 9am - 12pm US Central, not 10am. > >> On Jan 11, 2023, at 10:23 AM, Wes Bland via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: >> >> Hi all, >> >> As you hopefully remember from the December 2022 meeting, we’ve added a few additional virtual voting meetings for the 2023 calendar year in an effort to finish up MPI 4.1 by November. This is the planned meeting schedule for the year: >> >> 4 December 2023 - 7 December 2023 - Virtual Voting Meeting >> 31 October 2023 - 3 November 2023 - Virtual Voting Meeting >> 13 September 2023 - 15 September 2023 - Briston, UK (in conjunction with EuroMPI 2023) - exact dates may be still adjusted >> 10 July 2023 - 13 July 2023 - Virtual Voting Meeting >> 2 May 2023 - 5 May 2023 - Virtual Voting Meeting >> 13 March 2023 - 16 March 2023 - Boston, MA (Amazon) >> 1 February 2023 and 8 February 2023 - Virtual Voting Meeting - only 2/1 and 2/8 >> >> Registration is now open for the February meeting at this link. https://forms.gle/7q4pUVGGGDUXgZiD9 Please do so ASAP. Note that the February meeting will take place during the time usually reserved for non-voting virtual meetings (10am - 12pm, US Central) on Feb 1 and Feb 8. >> >> A number of votes and readings have already been “announced” after having been carried over from the December meeting. All of these topics are posted on the agenda page <http://127.0.0.1:4000/meetings/2023/02/agenda>. Anything not already posted on this page needs to be announced to the mailing list by EOD on March 18th. >> >> Thanks, >> Wes >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Re: [Mpi-forum] February 2023 Meeting Registration
by Wes Bland 11 Jan '23

11 Jan '23

Quick correction. The meeting times will be from 9am - 12pm US Central, not 10am. > On Jan 11, 2023, at 10:23 AM, Wes Bland via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > > Hi all, > > As you hopefully remember from the December 2022 meeting, we’ve added a few additional virtual voting meetings for the 2023 calendar year in an effort to finish up MPI 4.1 by November. This is the planned meeting schedule for the year: > > 4 December 2023 - 7 December 2023 - Virtual Voting Meeting > 31 October 2023 - 3 November 2023 - Virtual Voting Meeting > 13 September 2023 - 15 September 2023 - Briston, UK (in conjunction with EuroMPI 2023) - exact dates may be still adjusted > 10 July 2023 - 13 July 2023 - Virtual Voting Meeting > 2 May 2023 - 5 May 2023 - Virtual Voting Meeting > 13 March 2023 - 16 March 2023 - Boston, MA (Amazon) > 1 February 2023 and 8 February 2023 - Virtual Voting Meeting - only 2/1 and 2/8 > > Registration is now open for the February meeting at this link. https://forms.gle/7q4pUVGGGDUXgZiD9 Please do so ASAP. Note that the February meeting will take place during the time usually reserved for non-voting virtual meetings (10am - 12pm, US Central) on Feb 1 and Feb 8. > > A number of votes and readings have already been “announced” after having been carried over from the December meeting. All of these topics are posted on the agenda page <http://127.0.0.1:4000/meetings/2023/02/agenda>. Anything not already posted on this page needs to be announced to the mailing list by EOD on March 18th. > > Thanks, > Wes > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

February 2023 Meeting Registration
by Wes Bland 11 Jan '23

11 Jan '23

Hi all, As you hopefully remember from the December 2022 meeting, we’ve added a few additional virtual voting meetings for the 2023 calendar year in an effort to finish up MPI 4.1 by November. This is the planned meeting schedule for the year: 4 December 2023 - 7 December 2023 - Virtual Voting Meeting 31 October 2023 - 3 November 2023 - Virtual Voting Meeting 13 September 2023 - 15 September 2023 - Briston, UK (in conjunction with EuroMPI 2023) - exact dates may be still adjusted 10 July 2023 - 13 July 2023 - Virtual Voting Meeting 2 May 2023 - 5 May 2023 - Virtual Voting Meeting 13 March 2023 - 16 March 2023 - Boston, MA (Amazon) 1 February 2023 and 8 February 2023 - Virtual Voting Meeting - only 2/1 and 2/8 Registration is now open for the February meeting at this link. https://forms.gle/7q4pUVGGGDUXgZiD9 Please do so ASAP. Note that the February meeting will take place during the time usually reserved for non-voting virtual meetings (10am - 12pm, US Central) on Feb 1 and Feb 8. A number of votes and readings have already been “announced” after having been carried over from the December meeting. All of these topics are posted on the agenda page <http://127.0.0.1:4000/meetings/2023/02/agenda>. Anything not already posted on this page needs to be announced to the mailing list by EOD on March 18th. Thanks, Wes

1 0

MPI Virtual Meeting today (Jan. 11th) 10am CT
by Martin Schulz 11 Jan '23

11 Jan '23

Hi all, First – happy new year to all of you! I hope you all had a good start. Just as a quick reminder, we’ll restart our MPI virtual meeting series today (Jan. 11th) again, at the usual time (10am US CT) and the link is available via the MPI forum website. As discussed at the last forum meeting, the topics today are the deprecation of MPI_HOST (Julien) and query routines for HW topologies (Guillaume). See/talk to you all in a bit, Martin -- Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ) Email: schulzm(a)in.tum.de

1 0

Re: [Mpi-forum] ABI working group is live
by Guillaume Mercier 04 Jan '23

04 Jan '23

Hello Jeff, Could you add me to the group? My github id is GuillaumeMercier My email address is guillaume.mercier(a)u-bordeaux.fr Thanks Guillaume On 09/12/2022 07:31, Jeff Hammond via mpi-forum wrote: > The MPI ABI workgroup was approved. You can sign up for the mailing > list now: https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi > <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi>. > > If you want access to the GitHub group (https://github.com/mpiwg-abi/ > <https://github.com/mpiwg-abi/>), send me your GitHub username. > > If you want access to the Slack channel, DM me on Slack. If you are not > on Slack already, send me your email address. > > Jeff > > On Wed, Nov 16, 2022 at 9:54 AM Jeff Hammond <jeff.science(a)gmail.com > <mailto:[email protected]>> wrote: > > I don't know what we do to create new working groups with the > post-COVID rules, but I would like to create and chair a WG focused > on ABI standardization. > > There is strong support for this effort in many user communities, > including developers and maintainers of Spack, mpi4py, Julia MPI > (MPI.jl), Rust MPI (rsmpi), PETSc and NVHPC SDK, to name a few. > There are even a few implementers who have expressed support, but I > won't name them for their own protection. > > The problem is so exasperating for our users that there are at least > two different projects devoted to mitigating ABI problems (not > including shims built in to the aforementioned MPI wrappers): > > https://github.com/cea-hpc/wi4mpi <https://github.com/cea-hpc/wi4mpi> > https://github.com/eschnett/MPItrampoline > <https://github.com/eschnett/MPItrampoline> > > I've written about this a bit already, for those who are > interested. More material will be forthcoming once I have time for > more experiments. > > https://github.com/jeffhammond/blog/blob/main/MPI_Needs_ABI.md > <https://github.com/jeffhammond/blog/blob/main/MPI_Needs_ABI.md> > https://github.com/jeffhammond/blog/blob/main/MPI_Needs_ABI_Part_2.md <https://github.com/jeffhammond/blog/blob/main/MPI_Needs_ABI_Part_2.md> > https://github.com/jeffhammond/blog/blob/main/MPI_Needs_ABI_Part_3.md <https://github.com/jeffhammond/blog/blob/main/MPI_Needs_ABI_Part_3.md> > https://github.com/jeffhammond/blog/blob/main/MPI_Needs_ABI_Part_4.md <https://github.com/jeffhammond/blog/blob/main/MPI_Needs_ABI_Part_4.md> > > I understand this is a controversial topic, particularly for > implementers. I hope that we can proceed objectively. > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ <http://jeffhammond.github.io/> > > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ <http://jeffhammond.github.io/> > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0