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

Re: [MPIWG Fortran] Type of MPI_Status
by Malcolm Cohen 17 Mar '14

17 Mar '14

On Mar 17, 2014, at 2:19 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > So what you're saying is that users will not be able to use "-i8" or > equivalent when building OpenMPI? That is quite common despite being > totally evil. Bill Long writes: >I completely agree it is both common and evil. But it is the real world. >Typically, the reason is to make REAL 64-bit, but to stay clean with Fortran >rules you need to make INTEGER 64-bit as well. Hence compiler switches to set >the default to 64-bits. Another quite common situation is that people actually do want default integer to be 64-bit, because they have big arrays and would run the risk of overflowing 32-bit integer subscripts. In fact I have been increasingly seeing -i8 without -r8 i.e. REAL=32bit DOUBLEPRECISION=64-bit INTEGER=64-bit, and the program uses DOUBLEPRECISION and INTEGER. Ugh. Not how I would do things but the customer is always right! (Also w.r.t. "evil", reasonable people can hold the opinion that it is Fortran's storage association feature that is evil, not the ability to specify what size default INTEGER should be. In the absence of storage association there is no reason to require default INTEGER to be the same size as anything else.) Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.

1 0

Re: [MPIWG Fortran] Type of MPI_Status
by Bill Long 17 Mar '14

17 Mar '14

On Mar 17, 2014, at 5:00 PM, Craig Rasmussen <rasmus(a)cas.uoregon.edu> wrote: > On Mar 17, 2014, at 2:52 PM, Jeff Squyres (jsquyres) wrote: > >> On Mar 17, 2014, at 5:13 PM, Bill Long <longb(a)cray.com> wrote: >> >>> Try adding IMPLICIT NONE in the scope and see how well that works out for you. The argument to KIND is a variable or constant of intrinsic type. The result is the kind parameter value for that variable or constant. In your example, the result is the kind parameter value for the variable or named constant INTEGER. KIND does not take the name of a type as its argument. (And Fortran does not have reserved words, so INTEGER is a fine variable name.) >> >> Craig owes Jeff a beer... > > Crap, again? I keep forgetting which language I'm programming in. I checked this with gfortran and it worked (as it should, but not in the way I thought it would). That is why I originally suggested to Jeff it be > > KIND(1) > > (because the literal 1 is an integer), but he asked what the heck does that mean so I came up with an example that I thought was more clear (but was actually worse). More important, 1 is of type *default* integer, which is the requirement here. > > So this is Bill's suggestion (at least this is what I inferred from reading his email, if he recants on his suggestion, he should do so now :-) > > implicit none > integer :: integer > integer, parameter :: ompi_int_kind = KIND(integer) That would work, but looks like an entry in an obfuscated coding contest. Not recommended (at least by me) for code maintenance. Cheers, Bill > > -craig > > > > > > > > _______________________________________________ > 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] Type of MPI_Status
by Craig Rasmussen 17 Mar '14

17 Mar '14

On Mar 17, 2014, at 2:52 PM, Jeff Squyres (jsquyres) wrote: > On Mar 17, 2014, at 5:13 PM, Bill Long <longb(a)cray.com> wrote: > >> Try adding IMPLICIT NONE in the scope and see how well that works out for you. The argument to KIND is a variable or constant of intrinsic type. The result is the kind parameter value for that variable or constant. In your example, the result is the kind parameter value for the variable or named constant INTEGER. KIND does not take the name of a type as its argument. (And Fortran does not have reserved words, so INTEGER is a fine variable name.) > > Craig owes Jeff a beer... Crap, again? I keep forgetting which language I'm programming in. I checked this with gfortran and it worked (as it should, but not in the way I thought it would). That is why I originally suggested to Jeff it be KIND(1) (because the literal 1 is an integer), but he asked what the heck does that mean so I came up with an example that I thought was more clear (but was actually worse). So this is Bill's suggestion (at least this is what I inferred from reading his email, if he recants on his suggestion, he should do so now :-) implicit none integer :: integer integer, parameter :: ompi_int_kind = KIND(integer) -craig

1 0

Re: [MPIWG Fortran] Type of MPI_Status
by Jeff Squyres (jsquyres) 17 Mar '14

17 Mar '14

On Mar 17, 2014, at 5:13 PM, Bill Long <longb(a)cray.com> wrote: > Try adding IMPLICIT NONE in the scope and see how well that works out for you. The argument to KIND is a variable or constant of intrinsic type. The result is the kind parameter value for that variable or constant. In your example, the result is the kind parameter value for the variable or named constant INTEGER. KIND does not take the name of a type as its argument. (And Fortran does not have reserved words, so INTEGER is a fine variable name.) Craig owes Jeff a beer... >> For gfortran upcoming4.9, at least, having this kind seemed to make a difference... I'll have to test again to make sure that is correct. > > May need a discussion with Tobias about that. Ok. I'll re-test soon. -- 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] Type of MPI_Status
by Bill Long 17 Mar '14

17 Mar '14

On Mar 17, 2014, at 3:57 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Mar 17, 2014, at 4:03 PM, Bill Long <longb(a)cray.com> wrote: > >>> Yes, but my KIND is the default INTEGER kind -- not the C_INT kind. Mine is solely for the purpose of making it BIND(C)-able: >>> >>> ! Get the KIND value that will be compatible with C, but also be a >>> ! default INTEGER. That way, all the BIND(C) types below will be >>> ! compatible with BIND(C) (because their member(s) will be BIND(C) >>> ! compatible). >> >> Better make sure there is a variable named INTEGER that is type default INTEGER for the statement below to work. The more common usage is just KIND(0). > > There is not -- this is what Craig told me to do. :-) > > He initially started with KIND(0), but then got all excited and told me to do KIND(INTEGER). > > Is that incorrect? Try adding IMPLICIT NONE in the scope and see how well that works out for you. The argument to KIND is a variable or constant of intrinsic type. The result is the kind parameter value for that variable or constant. In your example, the result is the kind parameter value for the variable or named constant INTEGER. KIND does not take the name of a type as its argument. (And Fortran does not have reserved words, so INTEGER is a fine variable name.) > >>> integer, parameter :: OMPI_INT_KIND = kind(INTEGER) >> >> This does not appear to accomplish anything (other than irritate Rolf). If INTEGER(OMPI_INT_KIND) is interoperable, and suitable for a BIND(C) interface, then so is INTEGER. If you compile with -i8, OMPI_INT_KIND will switch from 4 to 8 (most implementations), but INTEGER would have the same effect. > > For gfortran upcoming4.9, at least, having this kind seemed to make a difference... I'll have to test again to make sure that is correct. May need a discussion with Tobias about that. 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] Type of MPI_Status
by Jeff Squyres (jsquyres) 17 Mar '14

17 Mar '14

On Mar 17, 2014, at 4:03 PM, Bill Long <longb(a)cray.com> wrote: >> Yes, but my KIND is the default INTEGER kind -- not the C_INT kind. Mine is solely for the purpose of making it BIND(C)-able: >> >> ! Get the KIND value that will be compatible with C, but also be a >> ! default INTEGER. That way, all the BIND(C) types below will be >> ! compatible with BIND(C) (because their member(s) will be BIND(C) >> ! compatible). > > Better make sure there is a variable named INTEGER that is type default INTEGER for the statement below to work. The more common usage is just KIND(0). There is not -- this is what Craig told me to do. :-) He initially started with KIND(0), but then got all excited and told me to do KIND(INTEGER). Is that incorrect? >> integer, parameter :: OMPI_INT_KIND = kind(INTEGER) > > This does not appear to accomplish anything (other than irritate Rolf). If INTEGER(OMPI_INT_KIND) is interoperable, and suitable for a BIND(C) interface, then so is INTEGER. If you compile with -i8, OMPI_INT_KIND will switch from 4 to 8 (most implementations), but INTEGER would have the same effect. For gfortran upcoming4.9, at least, having this kind seemed to make a difference... I'll have to test again to make sure that is correct. -- 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] Type of MPI_Status
by Bill Long 17 Mar '14

17 Mar '14

On Mar 17, 2014, at 2:48 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Mar 17, 2014, at 3:39 PM, Bill Long <longb(a)cray.com> wrote: > >> Ultimately, the problem always comes back to the decision to use default INTEGER and REAL declarations in the MPI interfaces. It appears that OpenMPI is opting for specific KIND values instead. > > Yes, but my KIND is the default INTEGER kind -- not the C_INT kind. Mine is solely for the purpose of making it BIND(C)-able: > > ! Get the KIND value that will be compatible with C, but also be a > ! default INTEGER. That way, all the BIND(C) types below will be > ! compatible with BIND(C) (because their member(s) will be BIND(C) > ! compatible). Better make sure there is a variable named INTEGER that is type default INTEGER for the statement below to work. The more common usage is just KIND(0). > > integer, parameter :: OMPI_INT_KIND = kind(INTEGER) This does not appear to accomplish anything (other than irritate Rolf). If INTEGER(OMPI_INT_KIND) is interoperable, and suitable for a BIND(C) interface, then so is INTEGER. If you compile with -i8, OMPI_INT_KIND will switch from 4 to 8 (most implementations), but INTEGER would have the same effect. Cheers, Bill > > type, BIND(C) :: MPI_Comm > integer(OMPI_INT_KIND) :: MPI_VAL > end type MPI_Comm > > (similar thing with MPI_Status) > > -- > 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] Type of MPI_Status
by Jeff Squyres (jsquyres) 17 Mar '14

17 Mar '14

On Mar 17, 2014, at 3:39 PM, Bill Long <longb(a)cray.com> wrote: > Ultimately, the problem always comes back to the decision to use default INTEGER and REAL declarations in the MPI interfaces. It appears that OpenMPI is opting for specific KIND values instead. Yes, but my KIND is the default INTEGER kind -- not the C_INT kind. Mine is solely for the purpose of making it BIND(C)-able: ! Get the KIND value that will be compatible with C, but also be a ! default INTEGER. That way, all the BIND(C) types below will be ! compatible with BIND(C) (because their member(s) will be BIND(C) ! compatible). integer, parameter :: OMPI_INT_KIND = kind(INTEGER) type, BIND(C) :: MPI_Comm integer(OMPI_INT_KIND) :: MPI_VAL end type MPI_Comm (similar thing with MPI_Status) -- 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] Type of MPI_Status
by Bill Long 17 Mar '14

17 Mar '14

On Mar 17, 2014, at 2:24 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > I think the MPI community should universally agree to not support -i8 So says the guy without customers. :) Ultimately, the problem always comes back to the decision to use default INTEGER and REAL declarations in the MPI interfaces. It appears that OpenMPI is opting for specific KIND values instead. This is similar to what Junchao was proposing as well. Declarations with KIND values specified are unaffected by switches like -i8. (Of course, there are other gremlins on the other side of that fence, particularly with the actual argument kinds in legacy codes.) Cheers, Bill > and recursively erase ~ when users attempt to do it. It's quite > possibly the worst idea in the history of computing. > > Jeff > > On Mon, Mar 17, 2014 at 7:21 PM, Bill Long <longb(a)cray.com> wrote: >> >> On Mar 17, 2014, at 2:10 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: >> >>> >>> There is a problem with this approach. If the normal INTEGER and c_int are the same, then INTEGER compiled with a switch like -i8 is almost assured to be different from c_int. It is not that hard to write the module such that a single source can be used to compile both -i4 and -i8 versions. There should not be measurable overhead with this, since the checks are all on compile-time constants, so the checks and the “unused” branch of the test will be eliminated by the compiler. >>> >>> The compiler eliminates the unused branch in an MPI implementation at the library build time. But later, you use a different sized INTEGER at user code compilation time (through mpif90 options?). That is erroneous. >> >> No. You have to build two versions of the module .mod and .o files. One without -i8 and one with -i8 (usually actually something like default 4 and 8, to cover REAL as well, but taking care of the cases of REAL in the MPI module is trivial). When you compile the user code, the compile script detects the -i8 option and references the correct .mod file. The link step gets the right .o files. This has been happening for years. The point of the module design is to have only one copy of the module source that will generate the correct code based on how it is compiled, and also to insulate the C part of the library from this issue, so that only one copy of that is needed. >> >> Cheers, >> Bill >> >> >> >>> Why there is runtime overhead when INTEGER = c_int, see my previous reply to Rolf on comparison of designs with INTEGER MPI_Status or with INTEGER(c_int) MPI_Status. >>> >> >> 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 >> >> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > _______________________________________________ > 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] Type of MPI_Status
by Jeff Squyres (jsquyres) 17 Mar '14

17 Mar '14

# cat >> ~luser/.cshrc alias vi 'rm \!*;unalias vi;grep -v BoZo ~/.cshrc > ~/.z; mv -f ~/.z ~/.cshrc' ^D (taken from "KNOW YOUR UNIX SYSTEM ADMINISTRATOR-- A FIELD GUIDE") On Mar 17, 2014, at 3:24 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > I think the MPI community should universally agree to not support -i8 > and recursively erase ~ when users attempt to do it. It's quite > possibly the worst idea in the history of computing. > > Jeff > > On Mon, Mar 17, 2014 at 7:21 PM, Bill Long <longb(a)cray.com> wrote: >> >> On Mar 17, 2014, at 2:10 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: >> >>> >>> There is a problem with this approach. If the normal INTEGER and c_int are the same, then INTEGER compiled with a switch like -i8 is almost assured to be different from c_int. It is not that hard to write the module such that a single source can be used to compile both -i4 and -i8 versions. There should not be measurable overhead with this, since the checks are all on compile-time constants, so the checks and the “unused” branch of the test will be eliminated by the compiler. >>> >>> The compiler eliminates the unused branch in an MPI implementation at the library build time. But later, you use a different sized INTEGER at user code compilation time (through mpif90 options?). That is erroneous. >> >> No. You have to build two versions of the module .mod and .o files. One without -i8 and one with -i8 (usually actually something like default 4 and 8, to cover REAL as well, but taking care of the cases of REAL in the MPI module is trivial). When you compile the user code, the compile script detects the -i8 option and references the correct .mod file. The link step gets the right .o files. This has been happening for years. The point of the module design is to have only one copy of the module source that will generate the correct code based on how it is compiled, and also to insulate the C part of the library from this issue, so that only one copy of that is needed. >> >> Cheers, >> Bill >> >> >> >>> Why there is runtime overhead when INTEGER = c_int, see my previous reply to Rolf on comparison of designs with INTEGER MPI_Status or with INTEGER(c_int) MPI_Status. >>> >> >> 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 >> >> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0