April 2013 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] Fortran proposal w.r.t. BIND(C)/logical/linker symbols/etc. (take 2)
by Bill Long 26 Apr '13

26 Apr '13

Interestingly, as I was writing the attached file, this email arrived. I'll try to point out differences. Overall, the attached version explicitly moves in the direction that Jeff suggested - that the spec should not require a particular implementation. On 4/26/13 1:26 PM, Jeff Squyres (jsquyres) wrote: > With lots of feedback and discussions since Craig's+my proposal on April 22, we have updated our proposal to be the following (remember: if everyone likes these ideas, then we can go see what this means in terms of the text of chapter 17): > > 1. Remove BIND(C) from all prototypes in the spec. > Agreed. > 2. As has been the case since MPI-1, all Fortran symbols must be interceptable at link time: > I guess I find this too vague. What is a "Fortran symbol" ? I prefer to spell out explicitly the required names without trying to identify whether the underlying code is written in Fortran, C, or Python. The tools that care about this need to know only the external name and also the calling convention used. That's enough as far as I can see. [Note: In the attached file, I did take an extra step in exempting the routines in A.2.12 through A.2.15 from having separate PMPI_* names. These routines are so trivial that intercepting them would seem to make no sense. Further, they are often only 1 line of code, so it would be far better to have the compiler just inline them (resulting on no external symbol to intercept). The tools library would, of course, still have the MPI_* names available to call of needed. They would just not intercept them. > Class 1: For all MPI routines "MPI_<foo>" with a void * choice argument, or with no choice argument: > > A) If mpif.h/mpi module is provided, an external must be provided with the name "MPI_<foo>" that uses the Fortran calling conventions and has INTEGER handle arguments, as specified in Annex A. > An external name of MPI_<foo>, by definition in the spec, has the C calling conventions, and already exists in the library this way. You cannot have an MPI_<foo> with Fortran calling conventions, or INTEGER arguments. I assume this is just a mistake. More likely, the name is mpi_<foo>_. Furthermore, this requirements conflates the external names with what environment is being used. These should be independent issues. > B) If the mpi_f08 module is provided, an external must be provided with the name "MPI_<foo>_<f08_buffer>" that uses the Fortran calling conventions and has derived type handle arguments, as specified in Annex A. > Again, having the Fortran routine name start with upper case letters is not a good idea. If this is not a mistake, it is doing what we are trying to get away from - it puts an unnecessary constraint on the implementation. To get a name of MPI_... you either have to specify BIND(C) [with we are trying to get rid of], or it forces the implementation to not write this routine in Fortran. That is the type of restriction that we're trying to get rid of. > Class 2: For all MPI routines "MPI_<foo>" with a descriptor choice argument: > > A) If mpif.h/mpi module is provided, an external must be provided with the name "MPI_<foo>_<old_descriptor>" that uses the Fortran calling conventions and has INTEGER handle arguments, as specified in Annex A. > > B) If the mpi_f08 module is provided, an external must be provided with the name "MPI_<foo>_<f08_descriptor>" that uses the Fortran calling conventions and has derived type handle arguments, as specified in Annex A. > My impression from an earlier exchange with Rolf was that it is also an option to have derived type handles and (void *) choice arguments. This is only through the mpi_f08 module, for compilers that do not support the TS yet. I included this option in my list (so I have 5 names, instead of the 4 listed here). If this combination is being removed, then I'm happy to adjust my proposal accordingly. > *** The exact suffixes <f08_buffer>, <old_descriptor>, and <f08_descriptor> are up for discussion. > Ditto for the MPI... as above. > 3. Implementations that want to use CONTAIN blocks for inlined implementations -- probably for performance reasons -- can supply 2 Fortran libraries: one with CONTAIN/inlined implementations, and a second one with interceptable symbols (perhaps this should be an Advice to Implementors?). > This misses the main point. Sorry. There is no reason to have two Fortran libraries. Or any Fortran libraries, for that matter, if the implementation chooses some other method that satisfies the requirements. The point, as you said before, is to not specify the implementation. Cheers, Bill -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

[MPI3 Fortran] Fortran proposal w.r.t. BIND(C)/logical/linker symbols/etc. (take 2)
by Jeff Squyres (jsquyres) 26 Apr '13

26 Apr '13

With lots of feedback and discussions since Craig's+my proposal on April 22, we have updated our proposal to be the following (remember: if everyone likes these ideas, then we can go see what this means in terms of the text of chapter 17): 1. Remove BIND(C) from all prototypes in the spec. 2. As has been the case since MPI-1, all Fortran symbols must be interceptable at link time: Class 1: For all MPI routines "MPI_<foo>" with a void * choice argument, or with no choice argument: A) If mpif.h/mpi module is provided, an external must be provided with the name "MPI_<foo>" that uses the Fortran calling conventions and has INTEGER handle arguments, as specified in Annex A. B) If the mpi_f08 module is provided, an external must be provided with the name "MPI_<foo>_<f08_buffer>" that uses the Fortran calling conventions and has derived type handle arguments, as specified in Annex A. Class 2: For all MPI routines "MPI_<foo>" with a descriptor choice argument: A) If mpif.h/mpi module is provided, an external must be provided with the name "MPI_<foo>_<old_descriptor>" that uses the Fortran calling conventions and has INTEGER handle arguments, as specified in Annex A. B) If the mpi_f08 module is provided, an external must be provided with the name "MPI_<foo>_<f08_descriptor>" that uses the Fortran calling conventions and has derived type handle arguments, as specified in Annex A. *** The exact suffixes <f08_buffer>, <old_descriptor>, and <f08_descriptor> are up for discussion. 3. Implementations that want to use CONTAIN blocks for inlined implementations -- probably for performance reasons -- can supply 2 Fortran libraries: one with CONTAIN/inlined implementations, and a second one with interceptable symbols (perhaps this should be an Advice to Implementors?). -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Jeff Squyres (jsquyres) 26 Apr '13

26 Apr '13

Craig walked me through Bill's proposal on the phone today. Here's my take: 1. With one exception, I agree with Bill's proposal... but for reasons different than his (see below). 2. The one exception is class 2 point 1: Craig and I would like to defer some mechanism like this to MPI-4. The reason that I agree with this proposal is because it is largely already covered by MPI-3 *because MPI-3 already says that the Fortran interfaces are optional* (i.e., the ï¿½AT LEAST ONE OF...ï¿½ language can refer to the optionality of the Fortran interfaces, not linker symbols). Because of that fact, this proposal redundant/unnecessary (although I like the categorization of class1/2, etc.). Additionally, Rolf and Hubert have convinced me (off list) that the ABI issue is important and we need to retain the behavior that was published in MPI-3 (i.e., that MPI subroutines that accept buffers have one standardized linker name, and MPI subroutines that accept descriptors have a second standardized linker name). I'll start a new thread (just because this one is already long) with all the feedback that weï¿½ve gotten so far, to include the 2-library proposal, etc. On Apr 24, 2013, at 10:46 AM, Bill Long <longb(a)cray.com> wrote: > > > On 4/24/13 8:41 AM, Jeff Squyres (jsquyres) wrote: >> On Apr 24, 2013, at 9:36 AM, Bill Long <longb(a)cray.com> wrote: >> >>>> You're imposing a specific implementation scheme. We can't allow that in the MPI spec. >>> >>> I disagree with the first sentence. I'm wanting to merely ALLOW a new scheme (which is better one that the current lot, in my opinion). >> >> Rolf's proposal mandates 3 specific implementation schemes. So I should have said "Rolf", not "you". :-) >> >>> So you are saying that disallowing better implementations is part of the mandate of the MPI spec? >> >> Don't be like that. >> > > I didn't mean to be mean. The Fortran standard has a lot of instances of disallowing things, and I was not sure if the same was true of MPI. > [I'm in the middle of a symposium all day today, so sorry about not being prompt with replies.] > >>>> One of the reasons I really, really dislike Rolf's proposal text is that it mandates one of three implementation choices. Not only does the MPI standard specifically stay away from all implementation issues in normative text, none of the 3 implementation choices that Rolf outlined are how Open MPI is implemented. >>> >>> Then I see that as a problem. We should be looking at ways to allow the OpenMPI implementation rather than prohibiting implementations that are different. >> >> >> The MPI spec takes great pains to not mandate any particular implementation at all. >> > > My view (inexperienced as it is) is that this section is mainly about specifying what symbol names need to be available so that the tools know what to look for/intercept. I'd be in favor of just listing the names and characteristics without commentary about how they get produced (i.e. remove the discussion about the implementation detail). Something like to following: > > Class 1: For an MPI routine MPI_xxx with a void * choice argument, or with no choice argument, the implementation shall provide at AT LEAST ONE of the following: > > 1) An external with the C name MPI_xxx and C calling conventions as specified in the C prototype in Annex A. > > 2) An external with the name "......" that uses the Fortran calling conventions and has INTEGER handle arguments, as specified in Annex A. > > 3) An external with the name "....." that uses the Fortran calling conventions and has derived type handle arguments, as specified in Annex A. > > > Class 2: For an MPI routine MPI_xxx with a descriptor choice argument, the implementation shall provide AT LEAST ONE of the following: > > 1) An external with the C name MPI_xxx_cdesc and C calling conventions... > > 2), 3) Similar to above. > > With rules like these, a tool would have a small list of names to look for, and the correct calling information about each. > > Cheers, > Bill > > > > -- > Bill Long longb(a)cray.com > Fortran Technical Support & voice: 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101 > > -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Rolf Rabenseifner 26 Apr '13

26 Apr '13

Yes, the two library versions may be a good idea. But still we need to define the interceptable linker names, i.e., the names according to A1 and A2 in my pdf, together with a method that the tools can detect whether a - A1 (no buffer or buffer as address pointer) or - A2 (buffer as descriptor according to the used Fortran compiler) interface is provided. Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "Craig Rasmussen" <rasmus(a)cas.uoregon.edu> > Cc: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Friday, April 26, 2013 2:28:28 PM > Subject: Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc. > I don't think I understand Bill's counter proposal. > > However, I think Craig just (accidentally?) hit on what might be a > good compromise: implementations are free to provide multiple Fortran > libraries: > > A. One library can use CONTAIN/be inlined and be what 99.999% of the > world will use. It can even be the default library (e.g., for > implementations that have mpifort wrapper compilers). > > B. The other can have interceptable symbols. > > And therefore since the implementation supports interceptable Fortran > symbols, it's compliant. > > With clever source code and/or build system in the implementation, the > same Fortran wrappers could probably be compiled twice to provide both > libraries. > > > > On Apr 24, 2013, at 12:56 PM, Craig Rasmussen <rasmus(a)cas.uoregon.edu> > wrote: > > > I actually like Bill's counter proposal. My only suggestion is that > > an implementation must implement all of one or more of the options. > > I think splitting the symbols up into various subsets needlessly > > complicates things for everyone: the standard, the implementations, > > the casual Fortran tool writer, and the C tool community. > > > > Some MPI implementations could easily create a compile time option > > to build separate libraries with one providing C symbol > > interceptability and the other providing Fortran symbol > > interceptability. > > > > By the way, Bill has a lot of experience on the Fortran standard's > > committee writing "standard legalese", something that is completely > > outside my skill set given my experience in writing text for > > scientific journals. So perhaps he can help with some of the text. > > > > Dictionary definition of legalese: the formal and technical language > > of legal documents that is often hard to understand > > > > Craig Rasmussen > > CAS Scientific Programmer > > rasmus(a)cas.uoregon.edu > > > > > > On Apr 24, 2013, at 7:46 AM, Bill Long wrote: > > > >> > >> > >> On 4/24/13 8:41 AM, Jeff Squyres (jsquyres) wrote: > >>> On Apr 24, 2013, at 9:36 AM, Bill Long <longb(a)cray.com> wrote: > >>> > >>>>> You're imposing a specific implementation scheme. We can't allow > >>>>> that in the MPI spec. > >>>> > >>>> I disagree with the first sentence. I'm wanting to merely ALLOW a > >>>> new scheme (which is better one that the current lot, in my > >>>> opinion). > >>> > >>> Rolf's proposal mandates 3 specific implementation schemes. So I > >>> should have said "Rolf", not "you". :-) > >>> > >>>> So you are saying that disallowing better implementations is part > >>>> of the mandate of the MPI spec? > >>> > >>> Don't be like that. > >>> > >> > >> I didn't mean to be mean. The Fortran standard has a lot of > >> instances of disallowing things, and I was not sure if the same was > >> true of MPI. > >> [I'm in the middle of a symposium all day today, so sorry about not > >> being prompt with replies.] > >> > >>>>> One of the reasons I really, really dislike Rolf's proposal text > >>>>> is that it mandates one of three implementation choices. Not > >>>>> only does the MPI standard specifically stay away from all > >>>>> implementation issues in normative text, none of the 3 > >>>>> implementation choices that Rolf outlined are how Open MPI is > >>>>> implemented. > >>>> > >>>> Then I see that as a problem. We should be looking at ways to > >>>> allow the OpenMPI implementation rather than prohibiting > >>>> implementations that are different. > >>> > >>> > >>> The MPI spec takes great pains to not mandate any particular > >>> implementation at all. > >>> > >> > >> My view (inexperienced as it is) is that this section is mainly > >> about specifying what symbol names need to be available so that the > >> tools know what to look for/intercept. I'd be in favor of just > >> listing the names and characteristics without commentary about how > >> they get produced (i.e. remove the discussion about the > >> implementation detail). Something like to following: > >> > >> Class 1: For an MPI routine MPI_xxx with a void * choice argument, > >> or with no choice argument, the implementation shall provide at AT > >> LEAST ONE of the following: > >> > >> 1) An external with the C name MPI_xxx and C calling conventions as > >> specified in the C prototype in Annex A. > >> > >> 2) An external with the name "......" that uses the Fortran calling > >> conventions and has INTEGER handle arguments, as specified in Annex > >> A. > >> > >> 3) An external with the name "....." that uses the Fortran calling > >> conventions and has derived type handle arguments, as specified in > >> Annex A. > >> > >> > >> Class 2: For an MPI routine MPI_xxx with a descriptor choice > >> argument, the implementation shall provide AT LEAST ONE of the > >> following: > >> > >> 1) An external with the C name MPI_xxx_cdesc and C calling > >> conventions... > >> > >> 2), 3) Similar to above. > >> > >> With rules like these, a tool would have a small list of names to > >> look for, and the correct calling information about each. > >> > >> Cheers, > >> Bill > >> > >> > >> > >> -- > >> Bill Long longb(a)cray.com > >> Fortran Technical Support & voice: 651-605-9024 > >> Bioinformatics Software Development fax: 651-605-9142 > >> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101 > >> > >> > > > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Jeff Squyres (jsquyres) 26 Apr '13

26 Apr '13

I don't think I understand Bill's counter proposal. However, I think Craig just (accidentally?) hit on what might be a good compromise: implementations are free to provide multiple Fortran libraries: A. One library can use CONTAIN/be inlined and be what 99.999% of the world will use. It can even be the default library (e.g., for implementations that have mpifort wrapper compilers). B. The other can have interceptable symbols. And therefore since the implementation supports interceptable Fortran symbols, it's compliant. With clever source code and/or build system in the implementation, the same Fortran wrappers could probably be compiled twice to provide both libraries. On Apr 24, 2013, at 12:56 PM, Craig Rasmussen <rasmus(a)cas.uoregon.edu> wrote: > I actually like Bill's counter proposal. My only suggestion is that an implementation must implement all of one or more of the options. I think splitting the symbols up into various subsets needlessly complicates things for everyone: the standard, the implementations, the casual Fortran tool writer, and the C tool community. > > Some MPI implementations could easily create a compile time option to build separate libraries with one providing C symbol interceptability and the other providing Fortran symbol interceptability. > > By the way, Bill has a lot of experience on the Fortran standard's committee writing "standard legalese", something that is completely outside my skill set given my experience in writing text for scientific journals. So perhaps he can help with some of the text. > > Dictionary definition of legalese: the formal and technical language of legal documents that is often hard to understand > > Craig Rasmussen > CAS Scientific Programmer > rasmus(a)cas.uoregon.edu > > > On Apr 24, 2013, at 7:46 AM, Bill Long wrote: > >> >> >> On 4/24/13 8:41 AM, Jeff Squyres (jsquyres) wrote: >>> On Apr 24, 2013, at 9:36 AM, Bill Long <longb(a)cray.com> wrote: >>> >>>>> You're imposing a specific implementation scheme. We can't allow that in the MPI spec. >>>> >>>> I disagree with the first sentence. I'm wanting to merely ALLOW a new scheme (which is better one that the current lot, in my opinion). >>> >>> Rolf's proposal mandates 3 specific implementation schemes. So I should have said "Rolf", not "you". :-) >>> >>>> So you are saying that disallowing better implementations is part of the mandate of the MPI spec? >>> >>> Don't be like that. >>> >> >> I didn't mean to be mean. The Fortran standard has a lot of instances of disallowing things, and I was not sure if the same was true of MPI. >> [I'm in the middle of a symposium all day today, so sorry about not being prompt with replies.] >> >>>>> One of the reasons I really, really dislike Rolf's proposal text is that it mandates one of three implementation choices. Not only does the MPI standard specifically stay away from all implementation issues in normative text, none of the 3 implementation choices that Rolf outlined are how Open MPI is implemented. >>>> >>>> Then I see that as a problem. We should be looking at ways to allow the OpenMPI implementation rather than prohibiting implementations that are different. >>> >>> >>> The MPI spec takes great pains to not mandate any particular implementation at all. >>> >> >> My view (inexperienced as it is) is that this section is mainly about specifying what symbol names need to be available so that the tools know what to look for/intercept. I'd be in favor of just listing the names and characteristics without commentary about how they get produced (i.e. remove the discussion about the implementation detail). Something like to following: >> >> Class 1: For an MPI routine MPI_xxx with a void * choice argument, or with no choice argument, the implementation shall provide at AT LEAST ONE of the following: >> >> 1) An external with the C name MPI_xxx and C calling conventions as specified in the C prototype in Annex A. >> >> 2) An external with the name "......" that uses the Fortran calling conventions and has INTEGER handle arguments, as specified in Annex A. >> >> 3) An external with the name "....." that uses the Fortran calling conventions and has derived type handle arguments, as specified in Annex A. >> >> >> Class 2: For an MPI routine MPI_xxx with a descriptor choice argument, the implementation shall provide AT LEAST ONE of the following: >> >> 1) An external with the C name MPI_xxx_cdesc and C calling conventions... >> >> 2), 3) Similar to above. >> >> With rules like these, a tool would have a small list of names to look for, and the correct calling information about each. >> >> Cheers, >> Bill >> >> >> >> -- >> Bill Long longb(a)cray.com >> Fortran Technical Support & voice: 651-605-9024 >> Bioinformatics Software Development fax: 651-605-9142 >> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101 >> >> > -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Craig Rasmussen 24 Apr '13

24 Apr '13

I actually like Bill's counter proposal. My only suggestion is that an implementation must implement all of one or more of the options. I think splitting the symbols up into various subsets needlessly complicates things for everyone: the standard, the implementations, the casual Fortran tool writer, and the C tool community. Some MPI implementations could easily create a compile time option to build separate libraries with one providing C symbol interceptability and the other providing Fortran symbol interceptability. By the way, Bill has a lot of experience on the Fortran standard's committee writing "standard legalese", something that is completely outside my skill set given my experience in writing text for scientific journals. So perhaps he can help with some of the text. Dictionary definition of legalese: the formal and technical language of legal documents that is often hard to understand Craig Rasmussen CAS Scientific Programmer rasmus(a)cas.uoregon.edu On Apr 24, 2013, at 7:46 AM, Bill Long wrote: > > > On 4/24/13 8:41 AM, Jeff Squyres (jsquyres) wrote: >> On Apr 24, 2013, at 9:36 AM, Bill Long <longb(a)cray.com> wrote: >> >>>> You're imposing a specific implementation scheme. We can't allow that in the MPI spec. >>> >>> I disagree with the first sentence. I'm wanting to merely ALLOW a new scheme (which is better one that the current lot, in my opinion). >> >> Rolf's proposal mandates 3 specific implementation schemes. So I should have said "Rolf", not "you". :-) >> >>> So you are saying that disallowing better implementations is part of the mandate of the MPI spec? >> >> Don't be like that. >> > > I didn't mean to be mean. The Fortran standard has a lot of instances of disallowing things, and I was not sure if the same was true of MPI. > [I'm in the middle of a symposium all day today, so sorry about not being prompt with replies.] > >>>> One of the reasons I really, really dislike Rolf's proposal text is that it mandates one of three implementation choices. Not only does the MPI standard specifically stay away from all implementation issues in normative text, none of the 3 implementation choices that Rolf outlined are how Open MPI is implemented. >>> >>> Then I see that as a problem. We should be looking at ways to allow the OpenMPI implementation rather than prohibiting implementations that are different. >> >> >> The MPI spec takes great pains to not mandate any particular implementation at all. >> > > My view (inexperienced as it is) is that this section is mainly about specifying what symbol names need to be available so that the tools know what to look for/intercept. I'd be in favor of just listing the names and characteristics without commentary about how they get produced (i.e. remove the discussion about the implementation detail). Something like to following: > > Class 1: For an MPI routine MPI_xxx with a void * choice argument, or with no choice argument, the implementation shall provide at AT LEAST ONE of the following: > > 1) An external with the C name MPI_xxx and C calling conventions as specified in the C prototype in Annex A. > > 2) An external with the name "......" that uses the Fortran calling conventions and has INTEGER handle arguments, as specified in Annex A. > > 3) An external with the name "....." that uses the Fortran calling conventions and has derived type handle arguments, as specified in Annex A. > > > Class 2: For an MPI routine MPI_xxx with a descriptor choice argument, the implementation shall provide AT LEAST ONE of the following: > > 1) An external with the C name MPI_xxx_cdesc and C calling conventions... > > 2), 3) Similar to above. > > With rules like these, a tool would have a small list of names to look for, and the correct calling information about each. > > Cheers, > Bill > > > > -- > Bill Long longb(a)cray.com > Fortran Technical Support & voice: 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101 > >

1 0

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Bill Long 24 Apr '13

24 Apr '13

On 4/24/13 8:41 AM, Jeff Squyres (jsquyres) wrote: > On Apr 24, 2013, at 9:36 AM, Bill Long <longb(a)cray.com> wrote: > >>> You're imposing a specific implementation scheme. We can't allow that in the MPI spec. >> >> I disagree with the first sentence. I'm wanting to merely ALLOW a new scheme (which is better one that the current lot, in my opinion). > > Rolf's proposal mandates 3 specific implementation schemes. So I should have said "Rolf", not "you". :-) > >> So you are saying that disallowing better implementations is part of the mandate of the MPI spec? > > Don't be like that. > I didn't mean to be mean. The Fortran standard has a lot of instances of disallowing things, and I was not sure if the same was true of MPI. [I'm in the middle of a symposium all day today, so sorry about not being prompt with replies.] >>> One of the reasons I really, really dislike Rolf's proposal text is that it mandates one of three implementation choices. Not only does the MPI standard specifically stay away from all implementation issues in normative text, none of the 3 implementation choices that Rolf outlined are how Open MPI is implemented. >> >> Then I see that as a problem. We should be looking at ways to allow the OpenMPI implementation rather than prohibiting implementations that are different. > > > The MPI spec takes great pains to not mandate any particular implementation at all. > My view (inexperienced as it is) is that this section is mainly about specifying what symbol names need to be available so that the tools know what to look for/intercept. I'd be in favor of just listing the names and characteristics without commentary about how they get produced (i.e. remove the discussion about the implementation detail). Something like to following: Class 1: For an MPI routine MPI_xxx with a void * choice argument, or with no choice argument, the implementation shall provide at AT LEAST ONE of the following: 1) An external with the C name MPI_xxx and C calling conventions as specified in the C prototype in Annex A. 2) An external with the name "......" that uses the Fortran calling conventions and has INTEGER handle arguments, as specified in Annex A. 3) An external with the name "....." that uses the Fortran calling conventions and has derived type handle arguments, as specified in Annex A. Class 2: For an MPI routine MPI_xxx with a descriptor choice argument, the implementation shall provide AT LEAST ONE of the following: 1) An external with the C name MPI_xxx_cdesc and C calling conventions... 2), 3) Similar to above. With rules like these, a tool would have a small list of names to look for, and the correct calling information about each. Cheers, Bill -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Jeff Squyres (jsquyres) 24 Apr '13

24 Apr '13

On Apr 24, 2013, at 9:36 AM, Bill Long <longb(a)cray.com> wrote: >> You're imposing a specific implementation scheme. We can't allow that in the MPI spec. > > I disagree with the first sentence. I'm wanting to merely ALLOW a new scheme (which is better one that the current lot, in my opinion). Rolf's proposal mandates 3 specific implementation schemes. So I should have said "Rolf", not "you". :-) > So you are saying that disallowing better implementations is part of the mandate of the MPI spec? Don't be like that. >> One of the reasons I really, really dislike Rolf's proposal text is that it mandates one of three implementation choices. Not only does the MPI standard specifically stay away from all implementation issues in normative text, none of the 3 implementation choices that Rolf outlined are how Open MPI is implemented. > > Then I see that as a problem. We should be looking at ways to allow the OpenMPI implementation rather than prohibiting implementations that are different. The MPI spec takes great pains to not mandate any particular implementation at all. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Bill Long 24 Apr '13

24 Apr '13

On 4/24/13 8:23 AM, Jeff Squyres (jsquyres) wrote: > On Apr 23, 2013, at 2:31 PM, Bill Long <longb(a)cray.com> wrote: > >>> There would be a huge backlash if Fortran symbols were not interceptable. >> >> That is exactly the opposite of what I've heard from the tools people. My impression is that they would be happy to have to only look for the C names. Why would there be backlash in this case? > > Here's a backlash from an implementor :-). I don't (and can't) always call the back-end public C symbols from Fortran. > > You're imposing a specific implementation scheme. We can't allow that in the MPI spec. I disagree with the first sentence. I'm wanting to merely ALLOW a new scheme (which is better one that the current lot, in my opinion). So you are saying that disallowing better implementations is part of the mandate of the MPI spec? > > One of the reasons I really, really dislike Rolf's proposal text is that it mandates one of three implementation choices. Not only does the MPI standard specifically stay away from all implementation issues in normative text, none of the 3 implementation choices that Rolf outlined are how Open MPI is implemented. > Then I see that as a problem. We should be looking at ways to allow the OpenMPI implementation rather than prohibiting implementations that are different. Cheers, Bill -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] New Fortran proposal w.r.t. BIND(C)/logical/etc.
by Jeff Squyres (jsquyres) 24 Apr '13

24 Apr '13

On Apr 23, 2013, at 3:18 PM, Craig Rasmussen <rasmus(a)cas.uoregon.edu> wrote: > Are you talking about MPI_Status_f2c (or others like MPI_Comm_c2f)? I don't know if these functions have the same requirements regarding PMPI. Someone else should comment. Yes, they have the same PMPI requirements as all other MPI functions. The only 2 MPI functions that are specifically excluded from PMPI requirements are MPI_Wtick and MPI_Wtime. >> No, you do not want this BIND(C). You get the problems with LOGICAL back again. (Not for this particular routine, but for others.) Just name the subroutine MPI_Recv in the module and get rid of the interface block. This is a thin wrapper and the Fortran name (mangled or otherwise) will likely not even show up in the executable. The actual call will to the C library routine, and that one is the only one the tools people see. > > But the Fortran name mangling and the potential lack of the symbol appearing altogether is the crux of the problem we are trying to solve. I have no problem with what you want to do, I just think we have to wait until MPI-4 to try and do it. +1. (and at the same time, fix the profiling scheme to be something "better" that avoids this whole mess in the first place, IMHO) -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0