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

Re: [MPIWG Fortran] Another MPI_SIZEOF question
by Bill Long 12 Jun '14

12 Jun '14

On Jun 12, 2014, at 2:22 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Jun 10, 2014, at 4:55 PM, William Gropp <wgropp(a)illinois.edu> wrote: > >> On SIZEOF, the language in the standard for the argument is >> >> a Fortran variable of numeric intrinsic type (choice) >> >> [snip] >> Thus, I believe that MPI_SIZEOF has the same choice parameter requirements of the communication routines such as MPI_SEND. > > Quick question on this: (I don't think any of us disagree -- this language includes both scalars and arrays) Does this include logicals and characters? The language says *numeric* intrinsic type. > The Fortran language is unambiguous on this issue: "Each intrinsic type is classified as a numeric type or a nonnumeric type. The numeric types are integer, real, and complex. The nonnumeric intrinsic types are character and logical." I assumed that is what was meant here. Cheers, Bill > Technically, a character and a logical have numerical values, but that's not how they're generally used. > > Bill: do you remember the intent of the word "numeric" here? > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & 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: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Bill Long 12 Jun '14

12 Jun '14

On Jun 12, 2014, at 2:19 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Jun 11, 2014, at 4:25 PM, Bill Long <longb(a)cray.com> wrote: > >>> Actually, this doesn't work, either. If you have an mpif.h that contains an "INTERFACE MPI_Sizeof", the compiler will treat it differently depending on whether it is included from source.f or source.f90 (and probably other variants, too). Gaahhh! >> >> Not sure why you say this. Unless the lines get too long because of long names, you can write an include file so that it works for both fixed and free source forms. The assumed source form is the only distinction to the compiler between source files that end in .f and .f90. > > Argh -- my Fortran ignorance rears its ugly head. Yes, indenting properly makes that problem go away. > > It's a tight squeeze, but the longest interface I can find is with COMPLEX(REAL128) and DIMENSION for 15 ranks; it barely fits into 72 columns: It is possible to have continuation lines by putting & in column 73 of the line to be continued (which fixed-source rules will see in the “comment” part of the line, and free-source will see as a continuation sentinel) and also a & in column 6 of the following continuation line (which fixed-source rules will see as the normal continuation character, and free-source allows and represents removal of any spaces between the two & characters). This CAN get foiled if the fixed-source compilation violates the “column 73-80 is a comment” rule by specifying a longer length for statement content. Some compilers do allow that. You can help avoid that by moving the trailing & out farther - say column 132. But there is always some risk from non-conforming compilers. > > COMPLEX(REAL128),DIMENSION(1,1,1,1,1,1,1,1,1,1,1,1,1,1,*)::x > > Quite ugly, of course. But with a perl script to generate all the possibilities (for maximum portability), it works. Yuck. > >> As you might recall from earlier conference calls, I prefer that nothing be added to mpif.h that was not there before. None of the new functions or constants. It should be frozen at MPI 2.2 for compatibility with legacy codes. If programmers want to use new features, they have to modify their sources anyway, and should change to using a module at the same time. > > There was unfortunately pushback from the Forum on this issue; we lost that battle. I seem to recall. But I interpreted the question as for what was desired for MPI 4.0, and my opinion on that question is still the same as before. Cheers, Bill > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & 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: [MPIWG Fortran] Another MPI_SIZEOF question
by Jeff Squyres (jsquyres) 12 Jun '14

12 Jun '14

On Jun 10, 2014, at 4:55 PM, William Gropp <wgropp(a)illinois.edu> wrote: > On SIZEOF, the language in the standard for the argument is > > a Fortran variable of numeric intrinsic type (choice) > > [snip] > Thus, I believe that MPI_SIZEOF has the same choice parameter requirements of the communication routines such as MPI_SEND. Quick question on this: (I don't think any of us disagree -- this language includes both scalars and arrays) Does this include logicals and characters? The language says *numeric* intrinsic type. Technically, a character and a logical have numerical values, but that's not how they're generally used. Bill: do you remember the intent of the word "numeric" here? -- 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: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Jeff Squyres (jsquyres) 12 Jun '14

12 Jun '14

On Jun 11, 2014, at 4:25 PM, Bill Long <longb(a)cray.com> wrote: >> Actually, this doesn't work, either. If you have an mpif.h that contains an "INTERFACE MPI_Sizeof", the compiler will treat it differently depending on whether it is included from source.f or source.f90 (and probably other variants, too). Gaahhh! > > Not sure why you say this. Unless the lines get too long because of long names, you can write an include file so that it works for both fixed and free source forms. The assumed source form is the only distinction to the compiler between source files that end in .f and .f90. Argh -- my Fortran ignorance rears its ugly head. Yes, indenting properly makes that problem go away. It's a tight squeeze, but the longest interface I can find is with COMPLEX(REAL128) and DIMENSION for 15 ranks; it barely fits into 72 columns: COMPLEX(REAL128),DIMENSION(1,1,1,1,1,1,1,1,1,1,1,1,1,1,*)::x Quite ugly, of course. But with a perl script to generate all the possibilities (for maximum portability), it works. Yuck. > As you might recall from earlier conference calls, I prefer that nothing be added to mpif.h that was not there before. None of the new functions or constants. It should be frozen at MPI 2.2 for compatibility with legacy codes. If programmers want to use new features, they have to modify their sources anyway, and should change to using a module at the same time. There was unfortunately pushback from the Forum on this issue; we lost that battle. -- 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: [MPIWG Fortran] Another MPI_SIZEOF question
by N.M. Maclaren 12 Jun '14

12 Jun '14

On Jun 10 2014, William Gropp wrote: > > The problem is that the standard also requires MPI_SIZEOF to be supported > by every version of the Fortran interfaces, even mpif.h. This was *not* > the case in MPI-2. The standard even acknowledges that MPI_SIZEOF > requires overloading, and that overloading definition is required in > mpif.h . Thus, mpif.h cannot be implemented in a way that supports a > Fortran 77 compiler. Another problem, that does not seem to have been raised, is that MPI_Sizeof is potentially unimplementable without a compiler extension in Fortran 77. There is no way of passing arguments that forbids copy-in/copy-out, and it is perfectly permissible for a compiler to change the storage representation for argument passing. I can't remember offhand if any did or does, but it wouldn't surprise me if some did or even do for scalar arguments. The same is true for C, incidentally, and was even more common with that. Quite a few compilers did weird and wonderful things with arguments. Even using interface blocks requires the library to know far more about the compiler and its options (and that's the gotcha!) than is decent. Regards, Nick Maclaren.

1 0

Re: [MPIWG Fortran] MPI_SIZEOF: redux
by N.M. Maclaren 12 Jun '14

12 Jun '14

On Jun 6 2014, Malcolm Cohen wrote: > >>Lots of user codes are using mpif.h > > So what has that got to do with deprecating MPI_SIZEOF? Nothing > whatsoever. Agreed. > Not to mention that not a single one of those people using the so-called > F77 binding are using a mere FORTRAN 77 compiler. Even the INCLUDE > "mpi.h" line is a Fortran 90 feature that is not present in FORTRAN 77. Sorry but, in practice, it isn't. It's a 'Fortran IV' extension to Fortran 66 (sometimes with syntactic differences) and 77, that has been nearly ubiquitous since the early 1970s. I agree that it didn't reach the standard until Fortran 90. It's explicitly one of the required extensions to Fortran 77 (see MPI 1.3, 2.5.1, lines 34-36). > But since STORAGE_SIZE is far from universally available, this falls at > the very first hurdle. (And alternative ways of computing sizeof in e.g. > pure Fortran 90 are, although easy to write, not particularly convenient > to use, so those fall at the second hurdle.) Are they? I can't think of any that are entirely portable, though I can think of several that will probably work on all current systems. I agree that such tricks are not something that anyone should be teaching or encouraging. Regards, Nick Maclaren.

1 0

Re: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Bill Long 11 Jun '14

11 Jun '14

On Jun 11, 2014, at 3:18 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Jun 11, 2014, at 4:07 PM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: > >> I open to suggestions. >> >> 1. One obvious possibility is to re-instate "extended Fortran support"-like language, a la MPI-2.2. This does not make it possible to have MPI_SIZEOF in mpif.h, however, so I don't think it really solves the problem. >> >> 2. Another possibility is to say that MPI_SIZEOF is only available in the mpi and mpi_f08 modules (e.g., add an exception in MPI-3.x 17.1.4 saying that MPI_SIZEOF support is excluded from mpif.h). Per Bill Gropp's email (http://lists.mpi-forum.org/mpiwg-fortran/2014/06/1572.php) we'll actually have to add exceptions / remove references to overloading for all mpif.h cases -- not just MPI_SIZEOF. > > > I accidentally hit "send" before adding: > > 3. Bill Gropp's suggestion (http://lists.mpi-forum.org/mpiwg-fortran/2014/06/1592.php) of removing "Fortran 77" support entirely. > > I'm not a big fan of effectively removing support for older Fortran compilers in a point release of MPI (i.e., 3.1 -- 4.0 might be a better candidate for this). But I acknowledge Bill's warning (the "As an alternative..." paragraph is the above-cited email) about selectively editing the text to allow "Fortran 77" compilers. > > Indeed, the problem is more insidious than we initially thought -- because it's not just "Fortran 77" codes that are affected, but any source.f code, because it will likely invoke compiler defaults that will preclude using INTERFACE blocks and other modern Fortran constructs. I’m not aware of any compiler like that, but I suppose it is possible. But, in general this seems like a pointless / silly convention to impose. A compiler switch to change the source form default is reasonable (and common). But why would you remove parts of the language? > > Hence, mpif.h really is stuck in the past. It is possible that the only reasonable solution is to make mpif.h safe for source.f-like behavior, and then deprecate mpif.h in MPI-4.0. > The idea of include files in Fortran of any sort is “stuck in the past”. Cheers, Bill > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & 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: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Bill Long 11 Jun '14

11 Jun '14

On Jun 11, 2014, at 3:07 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Jun 9, 2014, at 8:31 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > >> Yeah, I kinda came to that same conclusion over the weekend (that OMPI's MPI_SIZEOF support in mpif.h would have to depend on which Fortran compiler is used). Urrrgh... > > > Actually, this doesn't work, either. If you have an mpif.h that contains an "INTERFACE MPI_Sizeof", the compiler will treat it differently depending on whether it is included from source.f or source.f90 (and probably other variants, too). Gaahhh! Not sure why you say this. Unless the lines get too long because of long names, you can write an include file so that it works for both fixed and free source forms. The assumed source form is the only distinction to the compiler between source files that end in .f and .f90. > > This means that it is not possible -- and has never been possible -- to have an MPI-3.0 compliant MPI_SIZEOF interface in mpif.h. An errata is therefore required. > > I open to suggestions. > > 1. One obvious possibility is to re-instate "extended Fortran support"-like language, a la MPI-2.2. This does not make it possible to have MPI_SIZEOF in mpif.h, however, so I don't think it really solves the problem. > > 2. Another possibility is to say that MPI_SIZEOF is only available in the mpi and mpi_f08 modules (e.g., add an exception in MPI-3.x 17.1.4 saying that MPI_SIZEOF support is excluded from mpif.h). Per Bill Gropp's email (http://lists.mpi-forum.org/mpiwg-fortran/2014/06/1572.php) we'll actually have to add exceptions / remove references to overloading for all mpif.h cases -- not just MPI_SIZEOF. As you might recall from earlier conference calls, I prefer that nothing be added to mpif.h that was not there before. None of the new functions or constants. It should be frozen at MPI 2.2 for compatibility with legacy codes. If programmers want to use new features, they have to modify their sources anyway, and should change to using a module at the same time. Cheers, Bill P.S. For benefit of JH: My family ancestry is 25% each of Dutch, Danish, English, and, yes, GERMAN ! :) > > Thoughts? > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & 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: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Jeff Squyres (jsquyres) 11 Jun '14

11 Jun '14

On Jun 11, 2014, at 4:07 PM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: > I open to suggestions. > > 1. One obvious possibility is to re-instate "extended Fortran support"-like language, a la MPI-2.2. This does not make it possible to have MPI_SIZEOF in mpif.h, however, so I don't think it really solves the problem. > > 2. Another possibility is to say that MPI_SIZEOF is only available in the mpi and mpi_f08 modules (e.g., add an exception in MPI-3.x 17.1.4 saying that MPI_SIZEOF support is excluded from mpif.h). Per Bill Gropp's email (http://lists.mpi-forum.org/mpiwg-fortran/2014/06/1572.php) we'll actually have to add exceptions / remove references to overloading for all mpif.h cases -- not just MPI_SIZEOF. I accidentally hit "send" before adding: 3. Bill Gropp's suggestion (http://lists.mpi-forum.org/mpiwg-fortran/2014/06/1592.php) of removing "Fortran 77" support entirely. I'm not a big fan of effectively removing support for older Fortran compilers in a point release of MPI (i.e., 3.1 -- 4.0 might be a better candidate for this). But I acknowledge Bill's warning (the "As an alternative..." paragraph is the above-cited email) about selectively editing the text to allow "Fortran 77" compilers. Indeed, the problem is more insidious than we initially thought -- because it's not just "Fortran 77" codes that are affected, but any source.f code, because it will likely invoke compiler defaults that will preclude using INTERFACE blocks and other modern Fortran constructs. Hence, mpif.h really is stuck in the past. It is possible that the only reasonable solution is to make mpif.h safe for source.f-like behavior, and then deprecate mpif.h in MPI-4.0. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Jeff Squyres (jsquyres) 11 Jun '14

11 Jun '14

On Jun 9, 2014, at 8:31 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > Yeah, I kinda came to that same conclusion over the weekend (that OMPI's MPI_SIZEOF support in mpif.h would have to depend on which Fortran compiler is used). Urrrgh... Actually, this doesn't work, either. If you have an mpif.h that contains an "INTERFACE MPI_Sizeof", the compiler will treat it differently depending on whether it is included from source.f or source.f90 (and probably other variants, too). Gaahhh! This means that it is not possible -- and has never been possible -- to have an MPI-3.0 compliant MPI_SIZEOF interface in mpif.h. An errata is therefore required. I open to suggestions. 1. One obvious possibility is to re-instate "extended Fortran support"-like language, a la MPI-2.2. This does not make it possible to have MPI_SIZEOF in mpif.h, however, so I don't think it really solves the problem. 2. Another possibility is to say that MPI_SIZEOF is only available in the mpi and mpi_f08 modules (e.g., add an exception in MPI-3.x 17.1.4 saying that MPI_SIZEOF support is excluded from mpif.h). Per Bill Gropp's email (http://lists.mpi-forum.org/mpiwg-fortran/2014/06/1572.php) we'll actually have to add exceptions / remove references to overloading for all mpif.h cases -- not just MPI_SIZEOF. Thoughts? -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0