- mpiwg-abi - mailman3.cels.anl.gov

Re: [mpiwg-abi] meet next week to discuss predefined handle constants
by Koziol, Quincey 17 Feb '23

17 Feb '23

Hui has a good suggestion to the predefined handle issue and he said that he’d post it when it’s ready for review. I think talking again is a good idea also - I’m free from 9-1pm CT on Monday. Quincey On Feb 17, 2023, at 7:40 AM, Jeff Hammond <jeff.science(a)gmail.com<mailto:[email protected]>> wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. we need to have a meeting to discuss how to implement handles and predefined handle constants e.g. MPI_COMM_WORLD and MPI_INT. i think we have consensus that we will do e.g. typedef struct MPI_ABI_Datatype * MPI_Datatype; since that is the only option that provides type-safety. there is an open question about using integer literal constants (MPICH-style) or addresses (OMPI-style). there are merits to both. i want to get consensus so that i can update the ABI proposal one way or the other.https://www.when2meet.com/?18843291-UxaiH is for scheduling. i will set the meeting time on Monday morning. i can host Teams or Google Meet. if you prefer Zoom, you can agree to host it. jeff -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/ -- mpiwg-abi mailing list mpiwg-abi(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi

1 0

meet next week to discuss predefined handle constants
by Jeff Hammond 17 Feb '23

17 Feb '23

we need to have a meeting to discuss how to implement handles and predefined handle constants e.g. MPI_COMM_WORLD and MPI_INT. i think we have consensus that we will do e.g. typedef struct MPI_ABI_Datatype * MPI_Datatype; since that is the only option that provides type-safety. there is an open question about using integer literal constants (MPICH-style) or addresses (OMPI-style). there are merits to both. i want to get consensus so that i can update the ABI proposal one way or the other.https://www.when2meet.com/?18843291-UxaiH is for scheduling. i will set the meeting time on Monday morning. i can host Teams or Google Meet. if you prefer Zoom, you can agree to host it. jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-abi] MPI-5 ABI proposal
by Martin Schulz 24 Jan '23

24 Jan '23

Hi all, Regarding the version call: we also have the MPI_Get_library_version call, which has a similar intention. In fact, it is intended to be more strict than just the same ABI. Perhaps that is sufficient for the purpose here. 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 On 24.01.23, 17:53, "mpiwg-abi on behalf of Christoph Niethammer" <mpiwg-abi-bounces(a)lists.mpi-forum.org <mailto:[email protected]> on behalf of niethammer(a)hlrs.de <mailto:[email protected]>> wrote: Hi Dan, Heff, I am not sure if I like the idea of having another possible header file for *library-only* backward compatibility. >From a software installation perspective this looks like a nightmare to me to maintain in parallel. We are just getting rid of one header in Fortran currently. ;) Regarding the issue Dan brought up: I think it would be good to have at least a chance to check if MPI library and MPI header fit together. One idea here would be to introduce a library routine "MPI_Abi_version()" that returns the API version and having a macro constant MPI_ABI_VERSION in the header, that can be compared. This will work for applications or a tool to test if the library is build against the same ABI. However, it will not help a library to detect if an application was build with the matching MPI header. :/ Best, Christoph ----- Original Message ----- From: "Holmes, Daniel John" <daniel.john.holmes(a)intel.com <mailto:[email protected]>> To: "Jeff Hammond" <jeff.science(a)gmail.com <mailto:[email protected]>> Cc: mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> Sent: Tuesday, 24 January, 2023 16:45:36 Subject: Re: [mpiwg-abi] MPI-5 ABI proposal Hi Jeff, Thanks - I looked through quickly - there's nothing outlandish it there, IMHO - seems sensible/modest. Slide 9 question "both mpi.h and mpi_abi.h in same program?" Do you mean "in the same translation unit" or "in different libraries linked together into a single binary" or something else? I'm thinking that the World model encourages the user to pass a communicator from the place where MPI_INIT was called into each sub-program/library - there must be agreement between them on the type/value. There are a bunch of what-if scenarios here: passing an MPI_Status from one place to another using a parameter/return value suggests your option 1 is the correct answer there (language copy would work). Best wishes, Dan. From: mpiwg-abi <mpiwg-abi-bounces(a)lists.mpi-forum.org <mailto:[email protected]>> On Behalf Of Jeff Hammond Sent: 24 January 2023 15:01 To: mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> Subject: [mpiwg-abi] MPI-5 ABI proposal As requested, I have made a concrete proposal for the MPI-5 ABI. https://docs.google.com/presentation/d/1cU9ewMUa7w3eaRVtfzov8NinyjzNSp5nF_p… <https://docs.google.com/presentation/d/1cU9ewMUa7w3eaRVtfzov8NinyjzNSp5nF_p…> Request edit access if you want to paint the bike shed with me. Jeff -- Jeff Hammond jeff.science(a)gmail.com <mailto:[email protected]><mailto:[email protected] <mailto:[email protected]>> http://jeffhammond.github.io/ <http://jeffhammond.github.io/> -- mpiwg-abi mailing list mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi> -- mpiwg-abi mailing list mpiwg-abi(a)lists.mpi-forum.org <mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi <https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi>

1 0

Re: [mpiwg-abi] MPI-5 ABI proposal
by Jeff Hammond 24 Jan '23

24 Jan '23

I think we have to make the ABI change opt-in, because not breaking ABI backwards compatibility with existing implementations is one of the big reasons we don't already have an ABI standard. I share Christoph's concern here and prefer not to have a separate header file if we can avoid it. However, if we don't have a new header, we cannot interoperate between old and new ABIs. With a new header, the option exists, although we might not take it. There are other ways to deal with the header situation, such as a separate path, preprocessor macros, etc. There is no best option here. Every variety will cause a problem for somebody, although hopefully we can find an option that only causes minor problems in the worst case. Jeff On Tue, Jan 24, 2023 at 7:06 PM Holmes, Daniel John < daniel.john.holmes(a)intel.com> wrote: > Hi Christoph, > > I think the idea of "mpi_abi.h" is that everyone in the world immediately > adds 4 characters to every file that currently has "mpi.h" in it. An opt-in > approach. > > Another possibility is that "mpi.h" becomes the ABI version of the header > and we specify "mpi_impl.h" as the implementation-specific header currently > exposed by the implementation. An opt-out approach. > > If it's done right, no-one will (need/want to) opt out. > > Best wishes, > Dan. > > -----Original Message----- > From: Christoph Niethammer <niethammer(a)hlrs.de> > Sent: 24 January 2023 16:53 > To: Holmes, Daniel John <daniel.john.holmes(a)intel.com> > Cc: Jeff Hammond <jeff.science(a)gmail.com>; mpiwg-abi(a)lists.mpi-forum.org > Subject: Re: [mpiwg-abi] MPI-5 ABI proposal > > Hi Dan, Heff, > > I am not sure if I like the idea of having another possible header file > for *library-only* backward compatibility. > From a software installation perspective this looks like a nightmare to me > to maintain in parallel. We are just getting rid of one header in Fortran > currently. ;) > > Regarding the issue Dan brought up: > I think it would be good to have at least a chance to check if MPI library > and MPI header fit together. > One idea here would be to introduce a library routine "MPI_Abi_version()" > that returns the API version and having a macro constant MPI_ABI_VERSION in > the header, that can be compared. > > This will work for applications or a tool to test if the library is build > against the same ABI. > However, it will not help a library to detect if an application was build > with the matching MPI header. :/ > > Best, > Christoph > > ----- Original Message ----- > From: "Holmes, Daniel John" <daniel.john.holmes(a)intel.com> > To: "Jeff Hammond" <jeff.science(a)gmail.com> > Cc: mpiwg-abi(a)lists.mpi-forum.org > Sent: Tuesday, 24 January, 2023 16:45:36 > Subject: Re: [mpiwg-abi] MPI-5 ABI proposal > > Hi Jeff, > > Thanks - I looked through quickly - there's nothing outlandish it there, > IMHO - seems sensible/modest. > > Slide 9 question "both mpi.h and mpi_abi.h in same program?" > > Do you mean "in the same translation unit" or "in different libraries > linked together into a single binary" or something else? > > I'm thinking that the World model encourages the user to pass a > communicator from the place where MPI_INIT was called into each > sub-program/library - there must be agreement between them on the > type/value. > > There are a bunch of what-if scenarios here: passing an MPI_Status from > one place to another using a parameter/return value suggests your option 1 > is the correct answer there (language copy would work). > > Best wishes, > Dan. > > From: mpiwg-abi <mpiwg-abi-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff > Hammond > Sent: 24 January 2023 15:01 > To: mpiwg-abi(a)lists.mpi-forum.org > Subject: [mpiwg-abi] MPI-5 ABI proposal > > As requested, I have made a concrete proposal for the MPI-5 ABI. > > > https://docs.google.com/presentation/d/1cU9ewMUa7w3eaRVtfzov8NinyjzNSp5nF_p… > > Request edit access if you want to paint the bike shed with me. > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com<mailto:[email protected]> > http://jeffhammond.github.io/ > > -- > mpiwg-abi mailing list > mpiwg-abi(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-abi] MPI-5 ABI proposal
by Holmes, Daniel John 24 Jan '23

24 Jan '23

Hi Christoph, I think the idea of "mpi_abi.h" is that everyone in the world immediately adds 4 characters to every file that currently has "mpi.h" in it. An opt-in approach. Another possibility is that "mpi.h" becomes the ABI version of the header and we specify "mpi_impl.h" as the implementation-specific header currently exposed by the implementation. An opt-out approach. If it's done right, no-one will (need/want to) opt out. Best wishes, Dan. -----Original Message----- From: Christoph Niethammer <niethammer(a)hlrs.de> Sent: 24 January 2023 16:53 To: Holmes, Daniel John <daniel.john.holmes(a)intel.com> Cc: Jeff Hammond <jeff.science(a)gmail.com>; mpiwg-abi(a)lists.mpi-forum.org Subject: Re: [mpiwg-abi] MPI-5 ABI proposal Hi Dan, Heff, I am not sure if I like the idea of having another possible header file for *library-only* backward compatibility. From a software installation perspective this looks like a nightmare to me to maintain in parallel. We are just getting rid of one header in Fortran currently. ;) Regarding the issue Dan brought up: I think it would be good to have at least a chance to check if MPI library and MPI header fit together. One idea here would be to introduce a library routine "MPI_Abi_version()" that returns the API version and having a macro constant MPI_ABI_VERSION in the header, that can be compared. This will work for applications or a tool to test if the library is build against the same ABI. However, it will not help a library to detect if an application was build with the matching MPI header. :/ Best, Christoph ----- Original Message ----- From: "Holmes, Daniel John" <daniel.john.holmes(a)intel.com> To: "Jeff Hammond" <jeff.science(a)gmail.com> Cc: mpiwg-abi(a)lists.mpi-forum.org Sent: Tuesday, 24 January, 2023 16:45:36 Subject: Re: [mpiwg-abi] MPI-5 ABI proposal Hi Jeff, Thanks - I looked through quickly - there's nothing outlandish it there, IMHO - seems sensible/modest. Slide 9 question "both mpi.h and mpi_abi.h in same program?" Do you mean "in the same translation unit" or "in different libraries linked together into a single binary" or something else? I'm thinking that the World model encourages the user to pass a communicator from the place where MPI_INIT was called into each sub-program/library - there must be agreement between them on the type/value. There are a bunch of what-if scenarios here: passing an MPI_Status from one place to another using a parameter/return value suggests your option 1 is the correct answer there (language copy would work). Best wishes, Dan. From: mpiwg-abi <mpiwg-abi-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond Sent: 24 January 2023 15:01 To: mpiwg-abi(a)lists.mpi-forum.org Subject: [mpiwg-abi] MPI-5 ABI proposal As requested, I have made a concrete proposal for the MPI-5 ABI. https://docs.google.com/presentation/d/1cU9ewMUa7w3eaRVtfzov8NinyjzNSp5nF_p… Request edit access if you want to paint the bike shed with me. Jeff -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/ -- mpiwg-abi mailing list mpiwg-abi(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi

1 0

Re: [mpiwg-abi] MPI-5 ABI proposal
by Christoph Niethammer 24 Jan '23

24 Jan '23

Hi Dan, Heff, I am not sure if I like the idea of having another possible header file for *library-only* backward compatibility. >From a software installation perspective this looks like a nightmare to me to maintain in parallel. We are just getting rid of one header in Fortran currently. ;) Regarding the issue Dan brought up: I think it would be good to have at least a chance to check if MPI library and MPI header fit together. One idea here would be to introduce a library routine "MPI_Abi_version()" that returns the API version and having a macro constant MPI_ABI_VERSION in the header, that can be compared. This will work for applications or a tool to test if the library is build against the same ABI. However, it will not help a library to detect if an application was build with the matching MPI header. :/ Best, Christoph ----- Original Message ----- From: "Holmes, Daniel John" <daniel.john.holmes(a)intel.com> To: "Jeff Hammond" <jeff.science(a)gmail.com> Cc: mpiwg-abi(a)lists.mpi-forum.org Sent: Tuesday, 24 January, 2023 16:45:36 Subject: Re: [mpiwg-abi] MPI-5 ABI proposal Hi Jeff, Thanks - I looked through quickly - there's nothing outlandish it there, IMHO - seems sensible/modest. Slide 9 question "both mpi.h and mpi_abi.h in same program?" Do you mean "in the same translation unit" or "in different libraries linked together into a single binary" or something else? I'm thinking that the World model encourages the user to pass a communicator from the place where MPI_INIT was called into each sub-program/library - there must be agreement between them on the type/value. There are a bunch of what-if scenarios here: passing an MPI_Status from one place to another using a parameter/return value suggests your option 1 is the correct answer there (language copy would work). Best wishes, Dan. From: mpiwg-abi <mpiwg-abi-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond Sent: 24 January 2023 15:01 To: mpiwg-abi(a)lists.mpi-forum.org Subject: [mpiwg-abi] MPI-5 ABI proposal As requested, I have made a concrete proposal for the MPI-5 ABI. https://docs.google.com/presentation/d/1cU9ewMUa7w3eaRVtfzov8NinyjzNSp5nF_p… Request edit access if you want to paint the bike shed with me. Jeff -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/ -- mpiwg-abi mailing list mpiwg-abi(a)lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi

1 0

Re: [mpiwg-abi] MPI-5 ABI proposal
by Holmes, Daniel John 24 Jan '23

24 Jan '23

Hi Jeff, Thanks - I looked through quickly - there's nothing outlandish it there, IMHO - seems sensible/modest. Slide 9 question "both mpi.h and mpi_abi.h in same program?" Do you mean "in the same translation unit" or "in different libraries linked together into a single binary" or something else? I'm thinking that the World model encourages the user to pass a communicator from the place where MPI_INIT was called into each sub-program/library - there must be agreement between them on the type/value. There are a bunch of what-if scenarios here: passing an MPI_Status from one place to another using a parameter/return value suggests your option 1 is the correct answer there (language copy would work). Best wishes, Dan. From: mpiwg-abi <mpiwg-abi-bounces(a)lists.mpi-forum.org> On Behalf Of Jeff Hammond Sent: 24 January 2023 15:01 To: mpiwg-abi(a)lists.mpi-forum.org Subject: [mpiwg-abi] MPI-5 ABI proposal As requested, I have made a concrete proposal for the MPI-5 ABI. https://docs.google.com/presentation/d/1cU9ewMUa7w3eaRVtfzov8NinyjzNSp5nF_p… Request edit access if you want to paint the bike shed with me. Jeff -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/

1 0

MPI-5 ABI proposal
by Jeff Hammond 24 Jan '23

24 Jan '23

As requested, I have made a concrete proposal for the MPI-5 ABI. https://docs.google.com/presentation/d/1cU9ewMUa7w3eaRVtfzov8NinyjzNSp5nF_p… Request edit access if you want to paint the bike shed with me. Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpiwg-abi] Current proposal?
by Koziol, Quincey 18 Jan '23

18 Jan '23

Yes - having a draft / strawman proposal would be good. On Jan 18, 2023, at 10:21 AM, Jeff Hammond <jeff.science(a)gmail.com<mailto:[email protected]>> wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. We are currently debating a variety of design issues on https://github.com/mpiwg-abi/abi-issues/issues. If you think it would be constructive, I can just propose what I think we should do without waiting for consensus. Jeff ---------- Forwarded message ---------- From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com<mailto:[email protected]>> To: "mpiwg-abi(a)lists.mpi-forum.org<mailto:[email protected]>" <mpiwg-abi(a)lists.mpi-forum.org<mailto:[email protected]>> Cc: Bcc: Date: Mon, 9 Jan 2023 16:48:41 +0000 Subject: Current proposal? JeffH -- Is there a location that contains your current ABI proposal that we can all read? -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]> -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/ -- mpiwg-abi mailing list mpiwg-abi(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi

1 0

Re: [mpiwg-abi] looking for some ABI guidance
by Jeff Hammond 18 Jan '23

18 Jan '23

Sorry, I cannot figure out how to receive these emails normally but instead only see them because I am the list owner, and those messages were filtered away from inbox. If you look at mpi.h from OMPI 4.1.2, for example, you'll see things like this: #define MPI_COMM_WORLD OMPI_PREDEFINED_GLOBAL( MPI_Comm, ompi_mpi_comm_world) They use this code, which contains a useful explanation. /* * When initializing global pointers to Open MPI internally-defined * structs, some compilers warn about type-punning to incomplete * types. Therefore, when full struct definitions are unavailable * (when not building Open MPI), cast to an opaque (void *) pointer to * disable any strict-aliasing optimizations. Don't cast to (void *) * when building Open MPI so that we actually get the benefit of type * checking (because we *do* have the full type definitions available * when building OMPI). */ #if !OMPI_BUILDING #if defined(c_plusplus) || defined(__cplusplus) #define OMPI_PREDEFINED_GLOBAL(type, global) (static_cast<type> (static_cast<void *> (&(global)))) #else #define OMPI_PREDEFINED_GLOBAL(type, global) ((type) ((void *) &(global))) #endif #else #define OMPI_PREDEFINED_GLOBAL(type, global) ((type) &(global)) #endif In Open-MPI, these are link-time constants. However, it is possible to use incomplete struct pointers while also having compile-time constants, for the same reason that void * p = 0xDEADBEEF; is legal C code (albeit implementation-defined). See https://github.com/mpiwg-abi/abi-issues/wiki/Valid-Pointers-and-related for details. Jim and I also worked out that we can have compile-time constants and still have the named (constant) handles be symbols in the SO for dlsym purposes, if users say they want that. I'll write that up later. Jeff > ---------- Forwarded message ---------- > From: "Zhou, Hui" <zhouh(a)anl.gov> > To: "mpiwg-abi(a)lists.mpi-forum.org" <mpiwg-abi(a)lists.mpi-forum.org> > Cc: > Bcc: > Date: Mon, 9 Jan 2023 18:22:26 +0000 > Subject: Re: looking for some ABI guidance > We dived directly into the technical details (intptr_t vs void *). But > first, excuse my ignorance, how do built-in constants, e.g. MPI_INT, work > in OpenMPI? In MPICH, those are true constants. And it is a really nice > feature that (at least) I appreciate. We can ask users to simply print the > handle and deduce a lot of clues on the state of their program. But the > appreciation may stem from the fact that I am not a debugger fan. I thought > in the proposal of standardizing ABI, we are targeting true compile-time > constants, is it correct? Now, if they are compile-time constants, directly > casting it as a pointer would be something to frown upon. If we are not > directly casting but going through conversions in the compatibility layer, > then I don't see the differences from one side (intptr_t) to the other > (pointer). > > Random question (in the form of bullets, sorry): > > - If we're talking about standardizing a compatibility layer, and > - We're talking about using pointers for MPI handle types, and > - Open MPI handles are pointers already, and > - Per Hui's description, MPICH integer handles directly correlate to > pointers under the covers, then > - Why use (u)intptr_t? > > I.e., MPICH already uses pointers for the underlying MPI objects, and > they're (assumedly) typed. Hence, it may not be much of a stretch to use > typed pointers in the proposed compatibility layer, rather than schlupping > everything into a (u)intptr_t. > > -- > > Hui > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0