June 2009 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] Latex for community proposal
by Craig Rasmussen 23 Jun '09

23 Jun '09

On Jun 23, 2009, at 8:15 AM, Lionel, Steve wrote: > Yes, I do. Excellent. I won't be able to work on it until the later part of July, but then will have 2-3 weeks I can put some time in on it. -craig > > Steve > > -----Original Message----- > From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected] > ] On Behalf Of Craig Rasmussen > Sent: Tuesday, June 23, 2009 10:14 AM > To: MPI-3 Fortran working group > Subject: Re: [MPI3 Fortran] Latex for community proposal > Importance: Low > > I think that Steve Lionel also wants to help. > > -craig > > On Jun 22, 2009, at 9:58 AM, Jeff Squyres wrote: > >> We discussed in Menlo Park putting together a relatively short RFC >> PDF to pass around the Fortran J3 and programmer community outlining >> what our current plans are for the new MPI Fortran bindings (e.g., >> "use mpi3", MPI_COUNT_KIND, typed MPI handles, ...etc.). The intent >> is to include a list/text of the new stuff and some trivial MPI >> Fortran code showing concrete examples (e.g., the canonical "hello >> world" and "ring" examples). >> >> I have put a skeleton latex template up in a mercurial repository >> here: >> >> http://bitbucket.org/jsquyres/mpi3-fortran-latex/ >> >> Craig volunteered to do most of the writing. >> >> If you want write access, get a bitbucket.org account (they're free) >> and let me know your ID. I'll add you to the writers list. >> >> -- >> Jeff Squyres >> Cisco Systems >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

1 0

Re: [MPI3 Fortran] Latex for community proposal
by Jeff Squyres 23 Jun '09

23 Jun '09

Keep in mind that we're not talking official spec here yet -- this is more an RFC for the Fortran community. But we'll take all the writing help we can get, in both documents! :-) On Jun 23, 2009, at 10:15 AM, Lionel, Steve wrote: > Yes, I do. > > Steve > > -----Original Message----- > From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected] > ] On Behalf Of Craig Rasmussen > Sent: Tuesday, June 23, 2009 10:14 AM > To: MPI-3 Fortran working group > Subject: Re: [MPI3 Fortran] Latex for community proposal > Importance: Low > > I think that Steve Lionel also wants to help. > > -craig > > On Jun 22, 2009, at 9:58 AM, Jeff Squyres wrote: > > > We discussed in Menlo Park putting together a relatively short RFC > > PDF to pass around the Fortran J3 and programmer community outlining > > what our current plans are for the new MPI Fortran bindings (e.g., > > "use mpi3", MPI_COUNT_KIND, typed MPI handles, ...etc.). The intent > > is to include a list/text of the new stuff and some trivial MPI > > Fortran code showing concrete examples (e.g., the canonical "hello > > world" and "ring" examples). > > > > I have put a skeleton latex template up in a mercurial repository > > here: > > > > http://bitbucket.org/jsquyres/mpi3-fortran-latex/ > > > > Craig volunteered to do most of the writing. > > > > If you want write access, get a bitbucket.org account (they're free) > > and let me know your ID. I'll add you to the writers list. > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > mpi3-fortran mailing list > > mpi3-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Latex for community proposal
by Lionel, Steve 23 Jun '09

23 Jun '09

Yes, I do. Steve -----Original Message----- From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Craig Rasmussen Sent: Tuesday, June 23, 2009 10:14 AM To: MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] Latex for community proposal Importance: Low I think that Steve Lionel also wants to help. -craig On Jun 22, 2009, at 9:58 AM, Jeff Squyres wrote: > We discussed in Menlo Park putting together a relatively short RFC > PDF to pass around the Fortran J3 and programmer community outlining > what our current plans are for the new MPI Fortran bindings (e.g., > "use mpi3", MPI_COUNT_KIND, typed MPI handles, ...etc.). The intent > is to include a list/text of the new stuff and some trivial MPI > Fortran code showing concrete examples (e.g., the canonical "hello > world" and "ring" examples). > > I have put a skeleton latex template up in a mercurial repository > here: > > http://bitbucket.org/jsquyres/mpi3-fortran-latex/ > > Craig volunteered to do most of the writing. > > If you want write access, get a bitbucket.org account (they're free) > and let me know your ID. I'll add you to the writers list. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran _______________________________________________ mpi3-fortran mailing list mpi3-fortran(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

1 0

Re: [MPI3 Fortran] Latex for community proposal
by Craig Rasmussen 23 Jun '09

23 Jun '09

I think that Steve Lionel also wants to help. -craig On Jun 22, 2009, at 9:58 AM, Jeff Squyres wrote: > We discussed in Menlo Park putting together a relatively short RFC > PDF to pass around the Fortran J3 and programmer community outlining > what our current plans are for the new MPI Fortran bindings (e.g., > "use mpi3", MPI_COUNT_KIND, typed MPI handles, ...etc.). The intent > is to include a list/text of the new stuff and some trivial MPI > Fortran code showing concrete examples (e.g., the canonical "hello > world" and "ring" examples). > > I have put a skeleton latex template up in a mercurial repository > here: > > http://bitbucket.org/jsquyres/mpi3-fortran-latex/ > > Craig volunteered to do most of the writing. > > If you want write access, get a bitbucket.org account (they're free) > and let me know your ID. I'll add you to the writers list. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

1 0

Re: [MPI3 Fortran] Request for a straw vote.
by Bill Long 23 Jun '09

23 Jun '09

Lionel, Steve wrote: > Jeff Squyres wrote: > >> But what if a user compiles a code that uses INTEGERs where >> INTEGER(MPI_TAG_KIND) parameters are expected with "ifort - >> i8" (transmorgifying default INTEGERs to be 8 bytes)? Will their code >> refuse to compile? If so, do users expect / compensate for this kind >> of behavior? > > The code will compile fine, and the arguments declared with kind MPI_TAG_KIND will get that kind. Switches such as -i8 affect only "default integer" - declarations without a kind explicitly specified - at least in our implementation. > > A minor issue is that if -i8 is used and the programmer passes a default integer constant, such as 4, that will be INTEGER(8) and a mismatch. Intel Fortran will, as an extension, do a silent kind conversion for constant arguments. > And if the compiler is not so kind, then at least the user is on notice to fix the code. Error avoidance is one of the main virtues of explicit interfaces. On a big-endian machine (such as IBM) the difference between integer(4) and integer(8) really does matter for argument passing. > Note that if the interfaces are in a module, it is typically the case that the "default kind" in effect when the module source is compiled is what is used, so there really isn't a difference in terms of functionality whether the kinds are specified or not. Specifying the kinds is an aid to the programmer so they know what is expected, and so that they can declare their variables and constants with the correct kind, no matter what switches are used. It's simply good practice. > By specifying kind values everywhere in the module, the question of how the module was compiled becomes irrelevant. This is an additional reason for always specifying the kinds. > Steve Lionel > Intel Developer Support > Nashua, NH > > P.S. I am beside myself in amusement - Outlook correctly suggests "transmogrifying" as a spelling correction. I guess that Microsoft programmers are also Calvin and Hobbes fans. > Various Microsoft products flag "Fortran" as being misspelled. The suggested replacement is FORTRAN. One wavers between amusement and dismay at such incompetence. Cheers, Bill > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

1 0

Re: [MPI3 Fortran] Request for a straw vote.
by Lionel, Steve 23 Jun '09

23 Jun '09

Jeff Squyres wrote: > But what if a user compiles a code that uses INTEGERs where > INTEGER(MPI_TAG_KIND) parameters are expected with "ifort - > i8" (transmorgifying default INTEGERs to be 8 bytes)? Will their code > refuse to compile? If so, do users expect / compensate for this kind > of behavior? The code will compile fine, and the arguments declared with kind MPI_TAG_KIND will get that kind. Switches such as -i8 affect only "default integer" - declarations without a kind explicitly specified - at least in our implementation. A minor issue is that if -i8 is used and the programmer passes a default integer constant, such as 4, that will be INTEGER(8) and a mismatch. Intel Fortran will, as an extension, do a silent kind conversion for constant arguments. Note that if the interfaces are in a module, it is typically the case that the "default kind" in effect when the module source is compiled is what is used, so there really isn't a difference in terms of functionality whether the kinds are specified or not. Specifying the kinds is an aid to the programmer so they know what is expected, and so that they can declare their variables and constants with the correct kind, no matter what switches are used. It's simply good practice. Steve Lionel Intel Developer Support Nashua, NH P.S. I am beside myself in amusement - Outlook correctly suggests "transmogrifying" as a spelling correction. I guess that Microsoft programmers are also Calvin and Hobbes fans.

1 0

Re: [MPI3 Fortran] Request for a straw vote.
by Jeff Squyres 23 Jun '09

23 Jun '09

On Jun 22, 2009, at 12:08 PM, Lionel, Steve wrote: > >But I can also see that it would be a PITA for programmers to have to > >specify *every* argument to MPI functions, and potentially have to > >translate between their MPI-argument-variables and non-MPI-argument- > >variables. Shrug. > > No - programmers do NOT have to do this just because kinds are > specified. If default integer happens to match the declared kind, it > will just work without coding changes. If programmers want to use > the kinds, they can, and would be encouraged to, but it is not > required. > If an MPI implementation uses MPI_TAG_KIND for MPI message tags that are 4 bytes and are the same as default INTEGERs, then I can understand the logic here. But what if a user compiles a code that uses INTEGERs where INTEGER(MPI_TAG_KIND) parameters are expected with "ifort - i8" (transmorgifying default INTEGERs to be 8 bytes)? Will their code refuse to compile? If so, do users expect / compensate for this kind of behavior? -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Request for a straw vote.
by Jeff Squyres 23 Jun '09

23 Jun '09

On Jun 23, 2009, at 3:45 AM, Supalov, Alexander wrote: > Re 12: what if an array section is passed as an actual buffer > argument (i.e., a potentially noncontiguous area), and the MPI > datatype describes the data as such? Will the new interface avoid > copy-in/out? > Clearly, the interface has to allow this to work properly. Regardless of whether the MPI gets the descriptor and figures out the mapping, or whether it inhibits copying, or ...<something else>..., the interface has to allow non-contiguous buffers to be passed and work properly. -- Jeff Squyres Cisco Systems

1 0

Re: [MPI3 Fortran] Request for a straw vote.
by Supalov, Alexander 23 Jun '09

23 Jun '09

Re 12: what if an array section is passed as an actual buffer argument (i.e., a potentially noncontiguous area), and the MPI datatype describes the data as such? Will the new interface avoid copy-in/out? -----Original Message----- From: mpi3-fortran-bounces(a)lists.mpi-forum.org [mailto:[email protected]] On Behalf Of Jeff Squyres Sent: Monday, June 22, 2009 5:44 PM To: MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] Request for a straw vote. Sorry for being late to the discussion. On Jun 9, 2009, at 5:41 PM, Craig Rasmussen wrote: > 1. Q: Should intents be specified in the MPI-3 interfaces? > A: Yes, specifying intent in the Fortran interfaces helps the user > to understand the call (it may also help the compiler with > optimization). > Yes. > 2. Q: Should derived types be used in place of some MPI handles that > are currently integers? For example, TYPE(MPI_Comm). > A: Yes, the use of specific types enhances type safety. > Yes. Remember that MPI specifies that these are *handles* to back-end objects. Implementors can put whatever they want in handles; they just have to observe the defined handle semantics as listed in the MPI spec (this usually means that the handle is separate from the back-end object; the handle can be copied without copying the object, etc.) There's already good precedent for this in the MPI C++ bindings. > 3. Q: What type should be specified for the extra_state and value > parameters in MPI_Comm_create_keyval and MPI_Comm_attr_set? > A: TYPE(C_PTR). Use of C_PTR allows the MPI implementation to > store the address of the Fortran type and the user to subsequently > associate a Fortran pointer with the stored C_PTR with a call to > C_F_POINTER. > NOTE: C addresses are to be obtained using C_LOC which requires > the target attribute on the actual argument. This warns the compiler > that MPI may store (alias) the extra_state or value parameters. > I thought Hubert was right on this one: we decided to use TYPE(*), DIMENSION(..) to allow anything to go through (of course, that's a problem if scalars can't be specified this way). Perhaps the real Right answer here is to do whatever is done for MPI_SEND choice buffers (and friends) -- then at least we only continue that debate in one arena, not two. > 4. Q: What should the name of the MPI-3 module be? > A: MPI3 to distinguish it from the current MPI module. > Unresolved Issue: A consensus was not reached on this question. > An alternative is to use module names MPI2, MPI3, ..., as well as > MPI. If "USE MPI" is used, the MPI vendor will allow the module to be > chosen with a compile time option specifying the location of the MPI > module. > I prefer explicit versioning (e.g., "mpi3") since we *know* that the MPI-3 Fortran interface will be different and incompatible with the MPI-1 and MPI-2 Fortran interfaces, then having "use mpi" magically change to use the new interfaces will break old codes -- they'll refuse to compile. I think that's extremely undesirable. As previously mentioned, conversion functions will be provided that can be used to convert between C and MPI-1/MPI-2 Fortran handles and this new interface. > 5. Q: Should default integer kinds be used for most integer > parameters? > A: Yes, this has not caused problems in the past and will have the > least impact on existing code. > NOTE: A specified kind, MPI_COUNT_KIND will be used for buffer > count arguments. > I can see Alexander/Intel's position on this one: it has been a long- standing problem that users may have an MPI implementation that expects an INTEGER of size 4 bytes, but then the user compiled their application with "ifort -i8 ...", changing all the INTEGERS in their app to 8 bytes. Badness ensues when they use an 8 byte INTEGER to call an MPI function. But I can also see that it would be a PITA for programmers to have to specify *every* argument to MPI functions, and potentially have to translate between their MPI-argument-variables and non-MPI-argument- variables. Shrug. I think I fall on the side of "use default INTEGERs", though. The MPI can provide a "regular" INTEGER library, and a "-i8" INTEGER library. It's not perfect, but perhaps it's best to continue this uneasy compromise between programmer convenience / functionality and completeness-of-specification...? What does the Fortran community do for this issue in other software packages? > 6. Q: How should type and rank be specified for buffer choice > arguments? > A: TYPE(*), DIMENSION(..) > NOTE: This has been vetted by the Fortran J3 standards committee. > MPI vendors will use the Fortran descriptor interface. > Unresolved Issue 1: Will this block the compiler from using > copyin/ > copyout? > I tried to get involved in this debate and Alexander D. jumped all over my syntax. So I'll stay out. The intent is that *any* variable -- scalar or otherwise -- can be passed through this argument in a portable fashion (i.e., compiler- independent). If that means not specifying the actual language/ compiler mechanism but just specifying the mandated behavior, then so be it. One point that may have gotten lost in the email chain: Craig is correct that there is *NO RUSH* on specifying this. We can definitely wait for J3 to finalize its relevant specification(s) (e.g., TYPE(*), DIMENSION(..)). The Forum agrees on this point and definitely does not want to specify something based on a non-official/proposed J3 draft. > 7. Q: Are vendors allowed to provide a different actual interface in > the MPI-3 module for TYPE(*), DIMENSION(..) as a workaround until > compilers catch up. > A: Yes, if possible. > Unresolved issue: Can existing IGNORE TKR compiler directives be > used instead? > Ditto with #6. > 8. Q: Should the value attribute be given to some parameters? > A: No, it would be different from current semantics (though more > true to the C interface) and there is no need to make the change. > Specify intent instead. > No. > 9. Q: What syntax should be specified to inhibit aggresive compiler > optimizations associated with asynchronous MPI calls. > A: Used the Fortran asynchronous attribute on dummy variables. > NOTE: The MPI-3 standard will need to make clear that there are > requirements on the user to get this correct. > Staying out of this one for the same reason as #6. > 10. Q: Should specific Fortran interfaces be specified in the MPI-3 > standard? > A: Yes, this is preferable to use of <type> in the current > standard. While <type> is shorted, specific Fortran interfaces > provide greater clarity for users. > Yes, we should specify them because they will be different than the existing Fortran (77 style) bindings that are listed in the MPI-2.2 spec. Types will be different, etc. Hence, they really are two difference interfaces and need to be delineated. A reminder: the F90-style bindings are *not* listed anywhere in the MPI-2.2 spec. I assume that's because the types are all the same as the F77-style bindings that are listed throughout MPI-2.2. > 11. Q: Should the F77 and F90 interfaces be deprecated? > A: Yes. > NOTE: Old interface descriptions should be moved to an appendix. > Yes. Note: "deprecated" is not "removed". Either moving them to an appendix or marking them deprecated in the text (like we're about to do with the C++ bindings) are good solutions; they functions are still there, but we want everyone to use the new stuff. I agree that both the MPI spec and MPI implementations won't be removing them any time soon. Perhaps we can say "deprecated" in the spec for the old-style interfaces with appropriate language explaining that it is just our intent that people use the new stuff -- we're not abandoning the millions of LOC of legacy MPI Fortran apps. > 12. Q: Is it an error if the user gives a non-contiguous buffer to a > choice argument as it is for C? > A: Yes. > Unresolved issue: Should the vendor be required to catch the > error as always checking the argument is a performance issue. > NO!! I have seen this listed inaccurately in this thread multiple times: MPI does *NOT* say that it is an error to give a non-contiguous buffer as a choice buffer (in C or any language). This is *why* MPI has datatype arguments -- to describe the type map of the buffer. As Hubert indicated, it *must* be permissible to pass non-contiguous buffers as choice arguments and [somehow] have the underlying MPI do the Right Thing. Staying out of type/syntax discussions on this point for the same reasons as #6. > 13. Q: Should mixed MPI-3 and older MPI code be compatible within the > same application. > A: Yes, this allows a gentler transition path to MPI-3 if the > user doesn't have to convert all of this code at once. > NOTE: This will require conversion routines between, for example, > integer handles and MPI-3 typed handles. This would allow a > TYPE(MPI_Comm) to be converted to an integer and passed to code in a > user's older Fortran library. > Yes. I think we will need to outlaw mixing "include 'mpif.h'", "use mpi", and "use mpi3" (or whatever the new one is called) within the same block, though. I'm guessing that the types and/or values of MPI constants (e.g., MPI_COMM_WORLD) will conflict between these 3 mechanisms. -- Jeff Squyres Cisco Systems _______________________________________________ mpi3-fortran mailing list mpi3-fortran(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

Re: [MPI3 Fortran] Request for a straw vote.
by Aleksandar Donev 23 Jun '09

23 Jun '09

Lionel, Steve wrote: >> But I can also see that it would be a PITA for programmers to have to >> specify *every* argument to MPI functions, and potentially have to >> translate between their MPI-argument-variables and non-MPI-argument- >> variables. Shrug. > No - programmers do NOT have to do this just because kinds are specified. I am with Steve on this one. Kinds clarify distinctions, but are not the final word---they are simply an alias and will almost always point to the "default integer", so simple code will work. But, safer, clear code can be written as well. If we were talking about subtypes, it would be a more difficult discussion (compromise between ease and safety). This one seems to be a simple decision to me. Best, Aleks

1 0