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

Re: [MPI3 Fortran] MPI_SIZEOF question
by Rasmussen, Craig E 31 May '11

31 May '11

STORAGE_SIZE returns the size in bits so I'm not sure it is appropriate. I think C_SIZEOF would be better although it only works with interoperable types which I think is OK for MPI-3. But if the object is an array, C_SIZEOF returns the length (in bytes) of the entire array. I'm not sure what value MPI_SIZEOF is supposed to provide. Is it related to C? -craig On May 23, 2011, at 12:16 PM, Jeff Squyres wrote: > On May 23, 2011, at 10:47 AM, Bill Long wrote: > >> Ultimately, I'd be inclined to just scrap the routine as redundant. > > This function has been there since 1996 (i.e., MPI-2). > > Is it now obsolete? I.e., the Fortran instrinsic STORAGE_SIZE suitable? If so, we can deprecate the old MPI_SIZEOF function and not put it in the new MPI-3 fortran module... but it still has to be implemented in the existing MPI-2 fortran "use mpi" module (even if it's deprecated). > > Can you answer Rolf's questions? I'm particularly interested in the fortran wrapper questions. > > -- > 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

1 0

Re: [MPI3 Fortran] MPI_SIZEOF question
by Rasmussen, Craig E 31 May '11

31 May '11

Were you talking to me about answering Rolf's question? I'm trying to get through the email I missed (while in Alaska) this week. -craig On May 23, 2011, at 12:16 PM, Jeff Squyres wrote: > On May 23, 2011, at 10:47 AM, Bill Long wrote: > >> Ultimately, I'd be inclined to just scrap the routine as redundant. > > This function has been there since 1996 (i.e., MPI-2). > > Is it now obsolete? I.e., the Fortran instrinsic STORAGE_SIZE suitable? If so, we can deprecate the old MPI_SIZEOF function and not put it in the new MPI-3 fortran module... but it still has to be implemented in the existing MPI-2 fortran "use mpi" module (even if it's deprecated). > > Can you answer Rolf's questions? I'm particularly interested in the fortran wrapper questions. > > -- > 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

1 0

Re: [MPI3 Fortran] MPI_SIZEOF question
by Bill Long 23 May '11

23 May '11

On 5/23/11 1:16 PM, Jeff Squyres wrote: > On May 23, 2011, at 10:47 AM, Bill Long wrote: > >> Ultimately, I'd be inclined to just scrap the routine as redundant. > > This function has been there since 1996 (i.e., MPI-2). > > Is it now obsolete? I.e., the Fortran instrinsic STORAGE_SIZE suitable? If so, we can deprecate the old MPI_SIZEOF function and not put it in the new MPI-3 fortran module... but it still has to be implemented in the existing MPI-2 fortran "use mpi" module (even if it's deprecated). > I don't see MPI_SIZEOF as being necessary with STORAGE_SIZE available. How is MPI_SIZEOF implemented in MPI-2? > Can you answer Rolf's questions? I'm particularly interested in the fortran wrapper questions. > I tried. 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] MPI_SIZEOF question
by Bill Long 23 May '11

23 May '11

On 5/23/11 12:44 PM, Rolf Rabenseifner wrote: > > A) If we are doing BIND(C), I defined for MPI-3.0: > > INTERFACE > SUBROUTINE MPI_Sizeof(x, size, ierror) BIND(C) > IMPLICIT NONE > TYPE(*) :: x > INTEGER, INTENT(OUT) :: size > INTEGER, OPTIONAL, INTENT(OUT) :: ierror > END SUBROUTINE > END INTERFACE > > This seems to be ***bad*** because TYPE(*) is not enough to > get the dope vector Correct. No dope vector here - just an address. Not useful in this case. > TR 29113, 5.2.2, CFI_cdesc_t, > especially its structure element > > size_t elem_len; If the object corresponds to a Fortran > CHARACTER object, the value equals the length of > the CHARACTER object times the sizeof() of a scalar > of the character type; otherwise, the value equals > the sizeof() of an element of the object. > > We should do > > TYPE(*), DIMENSION(..) :: x > Better. dimension(..) will result in a (point to the) dope vector being passed. > which extends the current definition (in a backward compatible way). > > Then size = elem_len of the dope vector. > > Correct? Yes, assuming the caller knows the type. If you want the particular capitalization shown, you should make the first line of the routine subroutine MPI_Sizeof (x, size, ierror) BIND(C, name="MPI_Sizeof") Without the name= specifier, the external name will be mpi_sizeof (all lower case). This option seems like the best one - Fortran interface with C implementation. I assume this is not a performance sensitive routine, since there is overhead involved in creating the dope vector. > > B) If an implementation choose Fortran binding: > > B1) Does (without assumed-rank) > > SUBROUTINE MPI_Sizeof(x, size, ierror) > IMPLICIT NONE > TYPE(*) :: x > INTEGER, INTENT(OUT) :: size > INTEGER, OPTIONAL, INTENT(OUT) :: ierror > size = SIZEOF(x) > END SUBROUTINE > > work? No. SIZEOF is not a Fortran intrinsic, and there is no interface visible that indicates SIZEOF takes a type(*) argument. There is a STORAGE_SIZE intrinsic that provides similar functionality, but it is not in the list of intrinsics that allow a type(*) argument. > > B2) Does (with assumed-rank) > > SUBROUTINE MPI_Sizeof(x, size, ierror) > IMPLICIT NONE > TYPE(*), DIMENSION(..) :: x > INTEGER, INTENT(OUT) :: size > INTEGER, OPTIONAL, INTENT(OUT) :: ierror > size = SIZEOF(x) > END SUBROUTINE > > work, or how can it be programmed? This suffers from the same problem as the previous example, since it fails the restrictions on what can be done with a type(*) variable. An assumed-rank variable (dimension(..)) is allowed as an argument to STORAGE_SIZE, so it could be used in combination with explicit type arguments to greatly reduce the number of specifics in a generic interface. Still would need interfaces for (typically) 4 (integer) * 4 (logical) * 2 (real) * 2 (complex) * 1 (character) = 64 types. Compared to the C implementation, this seems clumsy. Cheers, Bill > > Best regards > Rolf > > > ----- Original Message ----- >> From: "Bill Long"<longb(a)cray.com> >> To: mpi3-fortran(a)lists.mpi-forum.org >> Sent: Monday, May 23, 2011 4:47:26 PM >> Subject: Re: [MPI3 Fortran] MPI_SIZEOF question >> >> The difficulty in writing things like this in Fortran is why the >> standard provides intrinsics. In this case, see STORAGE_SIZE, which >> returns the size of an array element of the type of the argument in >> bits. Dividing by 8 and multiplying by the array size (if the argument >> is not a scalar) should be simple enough for the user. >> >> On 5/23/11 8:30 AM, Jeff Squyres wrote: >>> I'm re-working Open MPI's Fortran implementation with Craig. >>> >>> The MPI_SIZEOF function is supposed to return the size of any >>> Fortran intrinsic data type. MPI-2.2 16.2.5 p494:31-44 says: >>> >>> ----- >>> The following functions allow a user to obtain a size-specific MPI >>> datatype for any intrinsic Fortran type. >>> >>> MPI_SIZEOF(x, size) >>> IN x a Fortran variable of numeric intrinsic type (choice) >>> OUT size size of machine representation of that type (integer) >>> >> >> This one is very close to STORAGE_SIZE. Just divide by 8. >> >>> MPI_SIZEOF(X, SIZE, IERROR) >>> <type> X >>> INTEGER SIZE, IERROR >>> >> >> This one would require also multiplying by the size of an array >> argument. I assume the IERROR is there only to provide a distinction >> for the generic interface. It is hard to imagine an actual run-time >> error with a routine like this. >> >> Ultimately, I'd be inclined to just scrap the routine as redundant. >> >> Cheers, >> Bill >> >> >>> This function returns the size in bytes of the machine >>> representation of the given variable. It is a generic Fortran >>> routine and has a Fortran binding only. >>> ----- >>> >>> Is there any way of implementing that other than an interface with >>> an overloaded subroutine for every single intrinsic type (including >>> dimension)? >>> >> >> -- >> 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 >> >> >> _______________________________________________ >> 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./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] MPI_SIZEOF question
by Jeff Squyres 23 May '11

23 May '11

On May 23, 2011, at 10:47 AM, Bill Long wrote: > Ultimately, I'd be inclined to just scrap the routine as redundant. This function has been there since 1996 (i.e., MPI-2). Is it now obsolete? I.e., the Fortran instrinsic STORAGE_SIZE suitable? If so, we can deprecate the old MPI_SIZEOF function and not put it in the new MPI-3 fortran module... but it still has to be implemented in the existing MPI-2 fortran "use mpi" module (even if it's deprecated). Can you answer Rolf's questions? I'm particularly interested in the fortran wrapper questions. -- 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] MPI_SIZEOF question
by Rolf Rabenseifner 23 May '11

23 May '11

A) If we are doing BIND(C), I defined for MPI-3.0: INTERFACE SUBROUTINE MPI_Sizeof(x, size, ierror) BIND(C) IMPLICIT NONE TYPE(*) :: x INTEGER, INTENT(OUT) :: size INTEGER, OPTIONAL, INTENT(OUT) :: ierror END SUBROUTINE END INTERFACE This seems to be ***bad*** because TYPE(*) is not enough to get the dope vector TR 29113, 5.2.2, CFI_cdesc_t, especially its structure element size_t elem_len; If the object corresponds to a Fortran CHARACTER object, the value equals the length of the CHARACTER object times the sizeof() of a scalar of the character type; otherwise, the value equals the sizeof() of an element of the object. We should do TYPE(*), DIMENSION(..) :: x which extends the current definition (in a backward compatible way). Then size = elem_len of the dope vector. Correct? B) If an implementation choose Fortran binding: B1) Does (without assumed-rank) SUBROUTINE MPI_Sizeof(x, size, ierror) IMPLICIT NONE TYPE(*) :: x INTEGER, INTENT(OUT) :: size INTEGER, OPTIONAL, INTENT(OUT) :: ierror size = SIZEOF(x) END SUBROUTINE work? B2) Does (with assumed-rank) SUBROUTINE MPI_Sizeof(x, size, ierror) IMPLICIT NONE TYPE(*), DIMENSION(..) :: x INTEGER, INTENT(OUT) :: size INTEGER, OPTIONAL, INTENT(OUT) :: ierror size = SIZEOF(x) END SUBROUTINE work, or how can it be programmed? Best regards Rolf ----- Original Message ----- > From: "Bill Long" <longb(a)cray.com> > To: mpi3-fortran(a)lists.mpi-forum.org > Sent: Monday, May 23, 2011 4:47:26 PM > Subject: Re: [MPI3 Fortran] MPI_SIZEOF question > > The difficulty in writing things like this in Fortran is why the > standard provides intrinsics. In this case, see STORAGE_SIZE, which > returns the size of an array element of the type of the argument in > bits. Dividing by 8 and multiplying by the array size (if the argument > is not a scalar) should be simple enough for the user. > > On 5/23/11 8:30 AM, Jeff Squyres wrote: > > I'm re-working Open MPI's Fortran implementation with Craig. > > > > The MPI_SIZEOF function is supposed to return the size of any > > Fortran intrinsic data type. MPI-2.2 16.2.5 p494:31-44 says: > > > > ----- > > The following functions allow a user to obtain a size-specific MPI > > datatype for any intrinsic Fortran type. > > > > MPI_SIZEOF(x, size) > > IN x a Fortran variable of numeric intrinsic type (choice) > > OUT size size of machine representation of that type (integer) > > > > This one is very close to STORAGE_SIZE. Just divide by 8. > > > MPI_SIZEOF(X, SIZE, IERROR) > > <type> X > > INTEGER SIZE, IERROR > > > > This one would require also multiplying by the size of an array > argument. I assume the IERROR is there only to provide a distinction > for the generic interface. It is hard to imagine an actual run-time > error with a routine like this. > > Ultimately, I'd be inclined to just scrap the routine as redundant. > > Cheers, > Bill > > > > This function returns the size in bytes of the machine > > representation of the given variable. It is a generic Fortran > > routine and has a Fortran binding only. > > ----- > > > > Is there any way of implementing that other than an interface with > > an overloaded subroutine for every single intrinsic type (including > > dimension)? > > > > -- > 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 > > > _______________________________________________ > 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: Allmandring 30)

1 0

Re: [MPI3 Fortran] MPI_SIZEOF question
by Bill Long 23 May '11

23 May '11

The difficulty in writing things like this in Fortran is why the standard provides intrinsics. In this case, see STORAGE_SIZE, which returns the size of an array element of the type of the argument in bits. Dividing by 8 and multiplying by the array size (if the argument is not a scalar) should be simple enough for the user. On 5/23/11 8:30 AM, Jeff Squyres wrote: > I'm re-working Open MPI's Fortran implementation with Craig. > > The MPI_SIZEOF function is supposed to return the size of any Fortran intrinsic data type. MPI-2.2 16.2.5 p494:31-44 says: > > ----- > The following functions allow a user to obtain a size-specific MPI datatype for any intrinsic Fortran type. > > MPI_SIZEOF(x, size) > IN x a Fortran variable of numeric intrinsic type (choice) > OUT size size of machine representation of that type (integer) > This one is very close to STORAGE_SIZE. Just divide by 8. > MPI_SIZEOF(X, SIZE, IERROR) > <type> X > INTEGER SIZE, IERROR > This one would require also multiplying by the size of an array argument. I assume the IERROR is there only to provide a distinction for the generic interface. It is hard to imagine an actual run-time error with a routine like this. Ultimately, I'd be inclined to just scrap the routine as redundant. Cheers, Bill > This function returns the size in bytes of the machine representation of the given variable. It is a generic Fortran routine and has a Fortran binding only. > ----- > > Is there any way of implementing that other than an interface with an overloaded subroutine for every single intrinsic type (including dimension)? > -- 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] MPI_SIZEOF question
by Jeff Squyres 23 May '11

23 May '11

I'm re-working Open MPI's Fortran implementation with Craig. The MPI_SIZEOF function is supposed to return the size of any Fortran intrinsic data type. MPI-2.2 16.2.5 p494:31-44 says: ----- The following functions allow a user to obtain a size-specific MPI datatype for any intrinsic Fortran type. MPI_SIZEOF(x, size) IN x a Fortran variable of numeric intrinsic type (choice) OUT size size of machine representation of that type (integer) MPI_SIZEOF(X, SIZE, IERROR) <type> X INTEGER SIZE, IERROR This function returns the size in bytes of the machine representation of the given variable. It is a generic Fortran routine and has a Fortran binding only. ----- Is there any way of implementing that other than an interface with an overloaded subroutine for every single intrinsic type (including dimension)? -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

[MPI3 Fortran] Fortran Official Reading Tickets #229 - #253 at May 9-11, 2011 meeting
by Rolf Rabenseifner 06 May '11

06 May '11

Dear all, two weeks ago, I send out a version for the formal reading. In the last two weeks i made several (most editorial) updates. I expect, that you represent an organization that uses Fortran or that has Fortran customers. Therefore, you may be heavily involved. On ticket https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/229 I have prepared a new version of the set of pdf files: Please can you print https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… and take it with you to our meeting at Cisco. It contains most of the solutions of the Fortran tickets and can be perfectly used for comments. It is a version without the deleted text and therefore best readable. If you have already printed and read and commented the version from April 21, 2011, then this is also fine. If you have not yet read and commented, then you should take this newest version with you. In the ticket's attachment zone, you find also a compilable version of the new module: https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-3.0-… Best regards and until Monday Rolf -- 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: Allmandring 30)

1 0

Re: [MPI3 Fortran] MPI draft 2011-04-21
by Malcolm Cohen 05 May '11

05 May '11

>> Pg 543, line 45: These named "constants" are an implementation detail >> and I don't understand why this is more than advice to implementors. > >It is important, that the user must not copy these constants. > buf = MPI_BOTTOM > MPI_SEND(buf, ...) >is invalid. Therefore here the reason and a pointer to Section 2.5.4. In Fortran 2003 and later this is more-or-less enforceable if you make the type of MPI_BOTTOM a private derived type. That prevents the user from declaring a variable of that type. >Does the Fortran standard guarantee that an array of a derived type >or a derived type with arrays as structure elements is internally >always stored as defined: No. > TYPE :: struct > REAL :: x, y, z > INTEGER :: geo > END TYPE struct > TYPE(struct) a(1000000) ... >Is the fortran compiler allowed to store it >as > > TYPE :: struct_iternal > REAL :: x(1000000), y(1000000), z(1000000) > INTEGER :: geo(1000000) > END TYPE struct > TYPE(struct) a In theory there is no requirement for any kind of uniform address space, contiguous storage, or even non-distributed storage. This has been exploited in the past on various massively-parallel machines. In practice on a conventional modern machine with a flat address space there are a lot of things it has to get right w.r.t. e.g. argument passing, array sectioning and subscripting which would make that infeasible without special hardware (or a lot of slow emulation). Why is this important? >I was told, that without the SEQUENCE attribute, >the compiler can do what it expect to be most efficient. >Is this true? Yes. >> Pg 552, two examples: These examples remind me that we need to >> carefully think where the TARGET attribute should/must be used in a >> valid MPI program. > >The other solutions for examples 16.13 and 16.14 >have been there and were described since July 1997. That does not mean that they were correct at that time. >I hope that they are still correct and that there is no case >where TARGET ***must be used*** instead of the other solutions. If buf does not have the TARGET attribute, MPI_GET_ADDRESS is not necessarily going to get the address of it! That's the whole point of TARGET... (and not having TARGET). VOLATILE does not solve that. Making it a module variable does not solve that. Playing with helper routines does not solve it as far as I can tell. These proposed "other solutions" appear to have been invalid since 1991. BTW, the "can be compiled as" columns seem to show fairly conservative optimisations... the compiler is at liberty to do much more to the code than these demonstrate. I'm not sure why the allergy to using TARGET to describe things you take an address of, since that is the very purpose of TARGET, and MPI's other target language C effectively gives every variable the TARGET attribute. >> Pg 553, line 6: Insert something like "MPI_F_SYNC_REG and the use of >> module data" are not guaranteed to work by the Fortran standard, >> though will likely work on most compilers. > >I'll add after "Each of these methods solve ... every application context.": > > These methods may not be guaranteed by the Fortran standard, > but they must be guaranteed by a \MPIIIIDOTO/ compliant (and later) > \MPI/ library and their compiler according to the requirements > listed in Section 16.2.16 on page 566. Seems to be p565 on my copy, maybe I'm looking at the wrong text or have a different version of the document. Given the decades-old (certainly pre-97) link-time optimisation technologies that have been and are being used, this seems to be misguided. >> Pg 554, first paragraph: MPI_F_SYNC_REG should be made BIND(C) to keep >> Fortran from very aggressive optimizations. Doesn't work against link-time optimisations. Doesn't work against various other compiler technologies in current use either. ... >The MPI Forum is in the conflict that it should keep the MPI >standard backward compatible. Thus, the DD must stay a valid >solution. It probably wasn't a valid solution then either. I appreciate that an apparent lack of backwards compatibility would be a problem, but remaining incompatible with long-established compiler technologies that are in use could also be considered to be a problem, and one that is only going to get worse in time. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.

1 0