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

Re: [MPI3 Fortran] MPI draft 2011-04-21
by Rolf Rabenseifner 30 Apr '11

30 Apr '11

Hubert, thank you very much for your in-deep reading. It is hard to keep such a new interface consistent with the rest of MPI and the Fortran standard and if you did not find more problems, then I'm happy! I'll do nearly all of your advices, therefore only a few comments: > (*) Page 545, Lines 36-40: > Therefore, ... and ",..., s(96)" in Line 40. This part is keppt,because the descriptor describes all these elements. > (*) Page 546, Line 17 and Line 21: > The font of _NOT_ in MPI_SUBARRAYS_NOT_SUPPORTED is too large. I used this larger font to highlight the "NOT" which should not be overread. > (*) Section Fortran Support Through the mpi_f08 Module and > Section Fortran Support Through the mpi Module > "Provide Interfaces for all MPI routines, ..." > Does all include the deprecated MPI routines ? I make it more clear: in mpi_f08 the deprecated routines must be included at least in the quality as in the mpi module. > What should item "Declare each argument with an INTENT=IN, OUT, or > INOUT as appropriate" mean ? Yes, I change to "as defined in this standard". Best regards Rolf ----- Original Message ----- > From: "Hubert Ritzdorf" <hritzdorf(a)hpce.nec.com> > To: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Friday, April 29, 2011 7:38:10 PM > Subject: Re: [MPI3 Fortran] MPI draft 2011-04-21 > Hi, > > I reviewed the draft and I propose only some small corrections to the > draft > > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… > > (*) Page 15 Line 1: > This is done by having two bindings where one has to optional argument > and one does not. > > This sentence is not really correct since at least functions > MPI_Dist_graph_create_adjacent and MPI_Dist_graph_neighbors have > 3 bindings since MPI_UNWEIGHTED can be used for 2 arguments. > > I would propose to simply remove the sentence. This is an > implementation > detail. > > (*) Page 546, Line 17 and Line 21: > The font of _NOT_ in MPI_SUBARRAYS_NOT_SUPPORTED is too large. > > (*) Page 552, Line 23: > > Remove "The" after "the" in "In Example, 16.12, the The compiler" > > (*) Page 553, Line 17: > applictions -> applications > > (*) Page 562, Line 9: > gerneric -> generic > > (*) Page 545, Lines 36-40: > MPI will work operate only on the elements s(1), s(6) s(11). > Therefore, remove the "etc.," in Line 36 and ",..., s(96)" in Line 40. > > (*) Page 558, Line 34: > autamatic -> automatic > > (*) Page 559, Line 7 > Add a newline before subsubsection "Fortran Support Though the mpif.h > Include File" > > (*) Page 564, Line 38: > interfces -> interfaces > > In addition, I have 2 questions to > > (*) Section Fortran Support Through the mpi_f08 Module and > Section Fortran Support Through the mpi Module > "Provide Interfaces for all MPI routines, ..." > > Does all include the deprecated MPI routines ? > > When looking for aim "compile-time checking", they should be included. > Since no Fortran 2008 interface is defined, it is not required that > they are included. What is right ? > > (*) Section 16.2.15 "Fortran Support Through the mpi_f08 Module" > > What should item "Declare each argument with an INTENT=IN, OUT, or > INOUT as appropriate" mean ? > > The MPI 3.0 draft defines all Intents. I would propose to remove this > item entirely or to change it into > "Declare each argument with an INTENT as defined in this standard" and > remove the rational. > > The following 4 items are also defined by each individual MPI > interface and could also be removed. > > Best regards > > Hubert > > > > > > > > > _______________________________________________ > 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 draft 2011-04-21
by Hubert Ritzdorf 29 Apr '11

29 Apr '11

Hi, I reviewed the draft and I propose only some small corrections to the draft https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… (*) Page 15 Line 1: This is done by having two bindings where one has to optional argument and one does not. This sentence is not really correct since at least functions MPI_Dist_graph_create_adjacent and MPI_Dist_graph_neighbors have 3 bindings since MPI_UNWEIGHTED can be used for 2 arguments. I would propose to simply remove the sentence. This is an implementation detail. (*) Page 546, Line 17 and Line 21: The font of _NOT_ in MPI_SUBARRAYS_NOT_SUPPORTED is too large. (*) Page 552, Line 23: Remove "The" after "the" in "In Example, 16.12, the The compiler" (*) Page 553, Line 17: applictions -> applications (*) Page 562, Line 9: gerneric -> generic (*) Page 545, Lines 36-40: MPI will work operate only on the elements s(1), s(6) s(11). Therefore, remove the "etc.," in Line 36 and ",..., s(96)" in Line 40. (*) Page 558, Line 34: autamatic -> automatic (*) Page 559, Line 7 Add a newline before subsubsection "Fortran Support Though the mpif.h Include File" (*) Page 564, Line 38: interfces -> interfaces In addition, I have 2 questions to (*) Section Fortran Support Through the mpi_f08 Module and Section Fortran Support Through the mpi Module "Provide Interfaces for all MPI routines, ..." Does all include the deprecated MPI routines ? When looking for aim "compile-time checking", they should be included. Since no Fortran 2008 interface is defined, it is not required that they are included. What is right ? (*) Section 16.2.15 "Fortran Support Through the mpi_f08 Module" What should item "Declare each argument with an INTENT=IN, OUT, or INOUT as appropriate" mean ? The MPI 3.0 draft defines all Intents. I would propose to remove this item entirely or to change it into "Declare each argument with an INTENT as defined in this standard" and remove the rational. The following 4 items are also defined by each individual MPI interface and could also be removed. Best regards Hubert

1 0

Re: [MPI3 Fortran] Derived-data, a new/late comment on Fortran WG5 ballot N1846
by Rolf Rabenseifner 21 Apr '11

21 Apr '11

I hope, it is possible to handle sequence derived types with in BIND(C) derived types in the same "friendly" way as normal INTEGER. It may not be interoperable, then it is worse a warning, but the problem must be handled by the C routine and I do not expect that anybody would deliver an MPI library is the case that C is not ableto handle a fortran numerical storage unit. I hope that the J3 committee finds the needed wording for the TR 29113 to include this. Happy Easter Rolf PS: I attached again the tests I've done and reported, see below. ----- Original Message ----- > From: "Reinhold Bader" <Reinhold.Bader(a)lrz.de> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "John Reid" <John.Reid(a)stfc.ac.uk>, interop-tr(a)j3-fortran.org > Cc: "Craig Rasmussen" <rasmussn(a)lanl.gov>, "Bill Long" <longb(a)cray.com>, "N.M. Maclaren" <nmm1(a)cam.ac.uk>, "Jeff > Squyres" <jsquyres(a)cisco.com>, "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Friday, April 15, 2011 12:53:34 PM > Subject: AW: Derived-data, a new/late comment on Fortran WG5 ballot N1846 > Hello all, > > with respect to "Problem A" I have the following (preliminary, given > my state of knowledge) opinion: > > Given the standard's *present* provisions (which makes an explicit > formal distinction between SEQUENCE and BIND(C)) > an implementation wishing to provide C interop faces the following > situation: > > (1) SEQUENCE types with interoperable ultimate components have the > same storage layout as BIND(C) types of the same structure > (2) SEQUENCE types do not have the same storage layout as said BIND(C) > types > > In case (1), an implementation may be liberal and accept (like e.g., > ifort does) non-conforming code. The latter may involve > SEQUENCE actual arguments in BIND(C) calls, or BIND(C) type components > in SEQUENCE types, or SEQUENCE components in BIND(C) types. > > In case (2), the implementation has no choice but to strictly follow > the standard's provisions, and reject any attempt to intermix > SEQUENCE with BIND(C). > > I don't know which implementations are of class (2), but any attempt > to make use of SEQUENCE legal with BIND(C) via the TR would > need to exclude such implementations. The only thing that could > conceivably be done for such implementations is to allow SEQUENCE > types as (non-VALUE) actual arguments in BIND(C) interfaces, and > require that the corresponding C prototype is a void *. This would > then on the C side force a programming style like > > typedef struct { > ... > } mytype; > > #ifdef CFI_SEQUENCE_MATCHES_C > void foo(mytype *obj) { > // reference obj via type components > } > #else > void foo(void *obj) { > // reference obj components via accessors which must be written in > Fortran > } > #endif > > > Regards > Reinhold > > > -----Ursprüngliche Nachricht----- > > Von: Rolf Rabenseifner [mailto:[email protected]] > > Gesendet: Donnerstag, 14. April 2011 16:23 > > An: John Reid; interop-tr(a)j3-fortran.org > > Cc: Bader, Reinhold; Craig Rasmussen; Bill Long; N.M. Maclaren; Jeff > > Squyres; > > MPI-3 Fortran working group > > Betreff: Derived-data, a new/late comment on Fortran WG5 ballot > > N1846 > > > > Dear John, dear members of the WG5 and J3 Fortran committees, > > > > I'm sorry that with this additional comment on problems regarding > > derived > > types, I missed the deadline of the N1846 ballot for the N1845 draft > > of the TR > > 29113 on extensions on Fortran-C interoperability. > > > > It looks like that there are two problems with derived types and the > > Fortran- > > MPI-compatibility with a background in the > > Fortran-C-interoperability. > > > > Problem A: Sequence derived types in the MPI routine > > interfaces, which are declared with BIND(C); > > this problem occurs with the new MPI handles > > and MPI statuses. > > > > Problem B: Derived type, SEQUENCE derived type, and > > BIND(C) derived type as actual user buffers > > for TYPE(*),DIMENSION(..) dummy arguments > > in BIND(C) MPI routine interfaces. > > > > Problem C: Based on problem B we have the question > > whether the new TYPE(*),DIMENSION(..) dummy > > arguments in BIND(C) MPI routine interfaces > > really allow all actual arguments that were > > possible with implicit interfaces or with > > explicit interfaces in combination with > > pragmas like > > !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf > > and > > !$PRAGMA IGNORE_TKR buf > > rest of the original mail: -------------------------- At least for problems A and B, the solution may be "simple" by allowing SEQUENCE derived types as element of a BIND(C) derived type and in BIND(C) subroutine dummy arguments. Why we need this is shown in very detail in the following description of Problems A and B. A still open question is Problem C. To Problem A: ------------- For better type-safety and compile-time argument-checking, the MPI Forum wants to use named types for MPI handles and MPI status. In MPI-1.1 up to MPI-2.2, we use INTEGER and INTEGER, DIMENSION(MPI_STATUS_SIZE) for this. With the new module mpi_f08 in MPI-3.0, we want to use MODULE mpi_f08 IMPLICIT NONE TYPE :: MPI_Comm SEQUENCE INTEGER :: MPI_VAL END TYPE MPI_Comm TYPE :: MPI_Status SEQUENCE INTEGER :: MPI_SOURCE INTEGER :: MPI_TAG INTEGER :: MPI_ERROR INTEGER :: MPI_intern_highsize INTEGER :: MPI_intern_lowsize END TYPE MPI_Status END MODULE mpi_f08 Within existing user applications, it is important, that the new handles and status variables can be used everywhere, where the old-style INTEGER handles and INTEGER-array statuses are already used. This definition can be used in - user-defined arrays of handles or statuses - handles and statuses as part of a user-defined common block - handles and statuses as part of a user-defined derived type - handles and statuses as part of a user-defined sequence derived type In my attached the tests Bu1.f90, Bu2.f90 and Bu3.f90, this was checked by Reinhold Bader for many compilers. If an application already uses C-Fortran interoperability, it may be that such handles and statuses are also declared with a BIND(C) derived type. The test Bu4.f90 showed that this works with ifort and pgi, but is rejected by gfortran, nagfor, xlf, crayftn, and pathscale. In the tests Au1, Au2, Au3, Au4, the SEQUENCE attribute was removed from the definition of MPI handles and statuses; nearly all compiler reject nearly all use-cases. In the tests Cu1, Cu2, Cu3, Cu4, the SEQUENCE was substituted by BIND(C). This is rejected by all compilers for the case that a handle or status is part of a user-defined sequence derived type (see Cu3). Another problem is the implementation of the MPI routines. We want to be able to use wrappers written in C, i.e., to use BIND(C) for the definition of MPI routines. The test Bc1 calls an MPI routine that has a pure Fortran implementation, while Bc2 calls an MPI routine that is implemented with BIND(C). Bc1 of course works with all compilers, while Bc2 is rejected by gfortran, nagfor, xlf and pathscale. Same rejections occur if the handles are defined without SEQUENCE (see Ac2). Of course, in case C, handles are done with BIND(C), all compiler accept the MPI routines (see Cc2), but this does not really help, because the application use-case Cu3 was rejected by all compilers. How can this problem be solved? Sequence derived types are similar to common blocks and as long as normal Fortran types (INTEGER, REAL) are allowed with BIND(C), why is a sequence of such types is not allowed with BIND(C)? Which additions would be necessary to solve this problem within the TR 29113? To Problem B: ------------- As an example, here an MPI interface SUBROUTINE MPI_xxx(buf,...) BIND(C) TYPE(*), DIMENSION(..) :: buf END within the new MPI module and the following user code TYPE :: user_xxx SEQUENCE REAL, DIMENSION(100) :: x, y, z INTEGER, DIMEMSION(20) :: a, b END TYPE user_xxx TYPE(user_xxx) :: strct(5) CALL MPI_xxx(strct, ...) When I understood correctly, then strct is handed over through a dope vector with elem_len = sizeof(strct(1)). Without any SEQUENCE or BIND(C) for user_xxx, the compiler may optimize and modify the memory layout of the structure during the execution of the application, i.e., any address difference need not to be constant, e.g., LOC(strct(5)%b(1)) - LOC(strct(1)%x(1)) need not to be the same during the whole execution and within the application and the called MPI routine. Is this correct? To achieve a well-defined memory layout, the user has to use SEQUENCE or BIND(C) for user_xxx. Therefore in the past, the advice for MPI users was, to use the SEQUENCE attribute. Results from the compiler tests are: All compiler allow the usage of SEQUENCE and BIND(C) derived type as actual buffer arguments in implicit interfaces of MPI routines, see cases 1 and 2 in the tests to problem B. All compiler with a IGNORE_TKR directive allow SEQUENCE and BIND(C) derived type as actual buffer arguments in an explicit interface defined with INTERFACE, see cases 4 and 5. Normal derived types (that are neither SEQUENCE, nor BIND(C), nor defined within a module) cannot be used as such an actual buffer argument with the IBM xlf compiler, see cases 3 and 6. Same results have been obtained with explicit interfaces defined with CONTAINS, except for xlf, which does not allow the IGNORE_TKR directive outside of INTERFACE declarations. Do I understand correctly, that with N1845 of TR 29113, TYPE(*),DIMENSION(..) works only with BIND(C) derived types, but - not with normal derived types, and - not with sequence derived types? Is there a possibility to extend the TR that also sequence derived type can be handed over to TYPE(*), DIMENSION(..) dummy arguments? Problem C: ---------- Do we have other actual arguments that could be used in implicit interfaces or in explicit interfaces with these special pragmas, and that are still forbidden for TYPE(*),DIMENSION(..) dummy arguments? Best regards and my apologies that we detected the problem not earlier, Rolf --------------------------------------------------------- Test and file names for Problem A: ---------------------------------- Implementing new MPI handles and status with ... A = Fortran derived type B = Fortran sequence derived type C = Fortran BIND(C) derived type Usage of new MPI handles and status in the application within ... u1 = a user defined common block u2 = a user defined derived type u3 = a user defined sequence derived type u4 = a user defined BIND(C) derived type Call an MPI routine that is defined c1 = without BIND(C) c2 = with BIND(C) Compiler: Result are: R - rejected by the compiler i - compiles but issues an information or warning y - compiles Test --> | A A A A A A | B B B B B B | C C C C C C | | u u u u c c | u u u u c c | u u u u c c | | 1 2 3 4 1 2 | 1 2 3 4 1 2 | 1 2 3 4 1 2 | ------------------+--------------+--------------+--------------+ ifort 6.1 | R y R y y y | y y y y y y | R y R y y y | ifort 11.1 | y y R y y y | y y y y y y | y y R y y y | ifort 12.0 | y y R y y y | y y y y y y | y y R y y y | ------------------+--------------+--------------+--------------+ gfortran 4.6 | R y R R y R | y y y R y R | i i R i i i | nagfor 5.2 | R i R R i R | y i i R i R | y i R i i i | ------------------+--------------+--------------+--------------+ xlf 13.1 | R y R R y R | y y y R y R | y y R y y y | crayftn 7.3 | R y R R y y | y y y R y y | y y R y y y | ------------------+--------------+--------------+--------------+ pgi 11.3 | y y R y y y | y y y y y y | y y R y y y | pathscale 3.3b | R i R R i R | i i i R i R | i i R i i i | ------------------+--------------+--------------+--------------+ Notes: "i" entries from the NAG compiler are due to defined but unused entities. "i" entries from the gfortran compiler are wrt INTEGER, ... potentially being non-interoperable. "i" entries from the Pathscale compiler are (irrelevant) link-time messages. Tar file: - MPI3_bind-C_sequence_tests.tar.gz (attached) ----------------------------------------------------------------- Test and file names for Problem B: ---------------------------------- Test and file names: derived_types_test_1_impl_integer.f90 derived_types_test_2_impl_sequ_bc.f90 derived_types_test_3_impl_derived.f90 derived_types_test_4_expl_integer.f90 derived_types_test_5_expl_sequ_bc.f90 derived_types_test_6_expl_derived.f90 derived_types_test_7_all.f90 derived_types_test_1+2_impl_int+seq+bc.f90 with impl = Implicitly defined MPI routine is called. expl = Two explicitly defined MPI routines are called - without BIND(C), - with BIND(C) in the subroutine declaration. The buf dummy argument is defined with a TKR ignore directive. integer = Actual argument is a derived type and it is passed through first (integer) element. Three different derived types are used: - normal, - with SEQUENCE attribute, - with BIND(C) attribute. sequ_bc = Actual argument is a derived type with - with SEQUENCE attribute, - with BIND(C) attribute. derived = Actual argument is a normal derived type. The last test "1+2" is a special test to show a compile-time error only detected by nagfor. This test compines the calls in ..._1_impl_integer.f90 and ..._2_impl_sequ_bc.f90. Compiler results may be: R - rejected by the compiler Rs - rejected by the compiler (routines and main separately compiled) i - compiles but issues an information or warning and runs correctly y - compiles and runs correctly ys - compiles and runs correctly (routines and main separately compiled) N - compiles, then runs with run time failure Test --> | ---impl--- ---expl--- all impl | int seq drv int seq drv int+seq | 1 2 3 4 5 6 7 1+2 ------------------+--------------------------------------- ifort 11.1 | y y y y y y y y ifort 12.0 | y y y y y y y y ------------------+--------------------------------------- gfortran 4.6 | y y y R R R R y nagfor 5.2 | ys ys ys Rs Rs Rs Rs Rs ------------------+--------------------------------------- xlf 13.1 | y y R y y R R y crayftn 7.3 | i i i y y y i i ------------------+--------------------------------------- pgi 11.3 | y y y y y y y y pathscale 3.3b | i i i y y y i i ------------------+--------------------------------------- Notes: - Compile-time information, warning and errors with the CALL statements gfortran + 1,all : Rank mismatch warning (rank-1 vs scalar lines for all invocations) gfortran + 2,3,all : Type mismatch warning gfortran + 4,all : Rank mismatch error (rank-1 vs scalar lines for all invocations), i.e., none of the TKR_IGNORE directives work gfortran + 5,6,all : Type mismatch error, i.e., none of the TKR_IGNORE directives work nagfor + 4,all : Rank mismatch error (rank-1 vs scalar lines for all invocations), i.e., none of the TKR_IGNORE directives work nagfor + 5,6,all : Type mismatch error, i.e., none of the TKR_IGNORE directives work nagfor + 1+2, all : Error: Inconsistency between several calls of implicitly defined routine: "Inconsistent data type INTEGER (previously USER_BUFFER_NORMAL_TYPE) for argument 3 in reference to FOO_IMPL", i.e., a combination of the tests in 1 and 2 or 3 may fail. crayftn+1,2,3,all,1+2 : Rank mismatch diagnosed, but runs correctly xlf + 3,6, all : Severe error: "A derived-type object that appears as an actual argument in an external procedure reference must be of a sequence type or a type with the BIND(C) attribute, unless it is use-associated or of a type that is use-associated or defined in the specification part of a module. pathscale+1-3,all,1+2 : Warns about rank mismatch, but runs correctly. - Compile-time information, warning and errors with the declaration statement of MPI_foo..., i.e., when compiling the MPI library: gfortran + 4,5,6,all : Warning with BIND(C) declarations: INTEGER may not be interoperable with C, related to line "SUBROUTINE MPI_foo_ex_c(c1,c2,buf,test1,test2) BIND(C)" nagfor + "routines" : Additional information that BIND(C) is an "extension" in line "SUBROUTINE MPI_foo_ex_c(c1,c2,buf,test1,test2) BIND(C)" - Other compile-time information, warning and errors: gfortran+1,2,4,5,all,1+2:Warning with BIND(C) declarations: INTEGER may not be interoperable with C, related to line "TYPE, BIND(C) :: user_buffer_bind_c_type" nagfor+1,2,4,5,all,1+2: Additional information that BIND(C) is an "extension" in line "TYPE, BIND(C) :: user_buffer_bind_c_type" - Runtime errors were never detected, i.e., in the cases with actual argument = buf%VAL1 (i.e., the first element of the derived type), all compilers used call by reference, i.e., the called implicit or explicit routines could correctly access also the second element of the derived type. Tar file: - MPI3_derived_types_test.tar.gz (attached) Acknowledgments: I want to thank Reinhold Bader (LRZ, Munich, Germany) who made all the compiler protocols. -- 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

[MPI3 Fortran] MPI draft 2011-04-21
by Rolf Rabenseifner 21 Apr '11

21 Apr '11

Dear all, at MPI ticket 229 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/229 I attached the draft for the MPI Form meeting May 9-11, 2011. For online reading, I recommend https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repo… (For the MPI Forum all information was in a separate mail.) For the Fortran J3/WG5: Most important pages are 13, 16, 545-558, 561-565 For me, it looks like that most problems are solved, because in MPI-draft-2011-04-21, Section 16.2.16, we make additional requirements for the combination of MPI & compiler. As you can see, the ASYNCHRONOUS in combination with the temporary data movements in MPI-draft-2011-04-21, Section 16.2.10 is kept unsolved if parts of an array are used for pending communication and other parts for computation. This may be solved in the future, not now. Therefore I withdraw our ASYNCHRONOUS-comment on the ballot 1846. More important for as is the handling of sequence derived types within BIND(C) derived types and BIND(C) routines in the dummy argument list. It would be helpful, if the requirements on page 564 line 19-31 and page 564 line 44 - page 565 line 3 are guaranteed by the TR 29113. Best regards 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] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by N.M. Maclaren 20 Apr '11

20 Apr '11

On Apr 20 2011, Bill Long wrote: > >Having the buf variable in a module is an effective method of solving >the "code motion across the MPI_Wait call" problem. And probably a good >recommended practice anyway. Unfortunately not, on both counts. Global optimisation (sometimes even at link time) is increasingly common, not least because it is essential for even reasonable efficiency with C. Such a compiler can tell that the MPI module makes no reference to the data module, directly or indirectly. Therefore, if the buffer does not have the ASYNCHRONOUS or TARGET attributes, code accessing it may be moved across the MPI_Wait. Also, this approach assumes that the only use of MPI is directly by the 'end users', and prevents libraries built on top of MPI from using non-blocking transfers. ScaLAPACK, FFTW, NAG and many others would be affected. >Craig also pointed out another reason for not including buf as an >argument to MPI_Wait. He argued, correctly, that the call to MPI_Wait >could be in a different program unit from the call to the >MPI_I{send/recv} call and, as a result, the name of buf might not be >visible at the point where MPI_Wait is called. To me this is a >definitive argument against a proposal to require buf in the MPI_Wait call. Agreed. Regards, Nick.

1 0

Re: [MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by Van Snyder 20 Apr '11

20 Apr '11

On Wed, 2011-04-20 at 02:35 -0700, Rolf Rabenseifner wrote: > Van and all Forum members, > > Why not including buf into the argument list of MPI_Wait? I've come to agree with Rolf and Nick that putting the buffer in MPI_Wait is unnecessary. The semantics of the ASYNCHRONOUS attribute are quite clear: It applies throughout the scoping unit, no matter where references to the asynchronous object appear. Putting the buffer in MPI_Wait wouldn't help anyway, unless we were to do away with GO TO.

1 0

Re: [MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by Bill Long 20 Apr '11

20 Apr '11

On 4/20/11 4:35 AM, Rolf Rabenseifner wrote: > Van and all Forum members, > > Why not including buf into the argument list of MPI_Wait? > > This was discussed already years ago: > - In the split collective routines, we did this already in the > original definition. > - MPI_Wait is part of a set of routines with > all having an array of request handles, i.e., > a set of such invisible buffers. > For those routines, such one additional argument > would not work. > - You are right that it would work exactly for MPI_Wait and MPI_Test > and if it is wanted by the MPI Forum, > I can add two new Fortran routines > MPI_Wait_f_sync_reg(buf,rq,ierror) > MPI_Test_f_sync_reg(buf,rq,flag,ierror) > - The question is, whether this duplication is necessary, > because the problem can be solved with different methods, > e.g., having buf as a module variable. > In this case the additional overhead for producing > the dope-vector for buf is not needed, Having the buf variable in a module is an effective method of solving the "code motion across the MPI_Wait call" problem. And probably a good recommended practice anyway. Craig also pointed out another reason for not including buf as an argument to MPI_Wait. He argued, correctly, that the call to MPI_Wait could be in a different program unit from the call to the MPI_I{send/recv} call and, as a result, the name of buf might not be visible at the point where MPI_Wait is called. To me this is a definitive argument against a proposal to require buf in the MPI_Wait call. Cheers, Bill > i.e., the existing MPI_Wait is the more efficient one. > > Comments from other members are highly appreciated. > > Best regards > Rolf > -- 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] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by N.M. Maclaren 20 Apr '11

20 Apr '11

On Apr 20 2011, Rolf Rabenseifner wrote: > >Van and all Forum members, > >Why not including buf into the argument list of MPI_Wait? No obvious reason, but it doesn't even help with the asynchronicity problems. What it does is to allow both eager and lazy execution for MPI non-blocking (though still not asynchronous). A much simpler solution, but one that I would regard as retrograde, is for MPI to forbid asynchronous transfers and allow only eager and lazy ones. > - MPI_Wait is part of a set of routines with > all having an array of request handles, i.e., > a set of such invisible buffers. > For those routines, such one additional argument > would not work. Actually, it would, but the details would be horribly messy. There is no way that I would want to teach them, for example. I would rather not go into them. > - You are right that it would work exactly for MPI_Wait and MPI_Test > and if it is wanted by the MPI Forum, > I can add two new Fortran routines > MPI_Wait_f_sync_reg(buf,rq,ierror) > MPI_Test_f_sync_reg(buf,rq,flag,ierror) That will NOT work! The problem is intermediate copying and caching in the call chain, for the case of genuinely asynchronous transfers. > - The question is, whether this duplication is necessary, > because the problem can be solved with different methods, > e.g., having buf as a module variable. > In this case the additional overhead for producing > the dope-vector for buf is not needed, > i.e., the existing MPI_Wait is the more efficient one. Again, that is NOT true. Firstly, it puts the constraint on programs to import the module directly in the procedure that actually calls the MPI_Wait or MPI_Wait_f_sync_reg, and that is not what a lot of programs do (or should do). Secondly, how do you propose to ensure that the object is not copied in the actual call to MPI_Wait or MPI_Wait_f_sync_reg? Fortran permits caller copying, there are several circumstances under which it requires it, and some compilers have done it in other cases. Lastly and most importantly, Fortran permits a compiler to copy a variable from a module and copy it back when the procedure returns, and some compilers have done just that with global entities. It can lead to significant performance improvements by improving caching. It doesn't matter HOW you cut it - there is NO WAY in Fortran to solve this problem without using ASYNCHRONOUS or an ASYNCHRONOUS-like attribute or (with some serious problems) TARGET. It's that simple. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by Rolf Rabenseifner 20 Apr '11

20 Apr '11

Van and all Forum members, Why not including buf into the argument list of MPI_Wait? This was discussed already years ago: - In the split collective routines, we did this already in the original definition. - MPI_Wait is part of a set of routines with all having an array of request handles, i.e., a set of such invisible buffers. For those routines, such one additional argument would not work. - You are right that it would work exactly for MPI_Wait and MPI_Test and if it is wanted by the MPI Forum, I can add two new Fortran routines MPI_Wait_f_sync_reg(buf,rq,ierror) MPI_Test_f_sync_reg(buf,rq,flag,ierror) - The question is, whether this duplication is necessary, because the problem can be solved with different methods, e.g., having buf as a module variable. In this case the additional overhead for producing the dope-vector for buf is not needed, i.e., the existing MPI_Wait is the more efficient one. Comments from other members are highly appreciated. Best regards Rolf ----- Original Message ----- > From: "Van Snyder" <Van.Snyder(a)jpl.nasa.gov> > To: interop-tr(a)j3-fortran.org > Cc: "Jeff Squyres" <jsquyres(a)cisco.com>, "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org>, "Rolf > Rabenseifner" <rabenseifner(a)hlrs.de> > Sent: Tuesday, April 19, 2011 10:35:53 PM > Subject: Re: [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846 > On Thu, 2011-04-14 at 13:03 -0700, Rolf Rabenseifner wrote: > > With > > CALL MPI_Irecv(buf, rq) > > CALL MPI_Wait(rq) > > CALL MPI_F_SYNC_REG(buf) > > xnew=buf > > > > > > The content of MPI_F_SYNC_REG is outside the scope of the > > Fortran optimization. > > I do not see that the compiler is allowed to move > > "xnew=buf" before the MPI_Wait statement because > > "MPI_F_SYNC_REG(buf)" may have modified the content of buf. > > > > Therefore the problem is solved. > > > > Correct? > > > > If not, please can you show a detailed code, how > > such a compiled code could work and in xnew is at the end > > ***not*** the value that was stored in buf by MPI_Wait. > > If this works, why not change the Fortran -> MPI interface for > MPI_Wait > to include "buf" instead of attaching the TARGET attribute to "buf" > and > hoping the processor will guess that implies that a pointer to "buf" > might be hiding in "rq"? After all, the processor can see "rq" and its > type (which might actually be TYPE(*)?), so it might (reasonably) > conclude from its analysis that "rq" doesn't contain any pointers to > "buf". -- 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] [Interop-tr] [Mpi-forum] Comment on Fortran WG5 ballot N1846
by Rasmussen, Craig E 19 Apr '11

19 Apr '11

Array of buffer arguments (array of pointers to buffer arguments?) would indeed be icky. But it is not likely that a user is really overlapping communication with computation on all of the buffers involved in the MPI_WAITALL call. So perhaps one extra overloaded argument for a buffer is OK. Doesn't change existing practice or codes (can't do that or I'll get in trouble with Rolf again :-) -craig On Apr 19, 2011, at 4:37 PM, Van Snyder wrote: > > On Tue, 2011-04-19 at 14:53 -0700, Jeff Squyres wrote: >> >> 1. The signature of MPI_WAIT (and friends) has been around for 18 >> years and there's lots of codes using it. It would be fairly >> disruptive to change it. >> >> This may be a weak argument; the other 2 are stronger. >> >> 2. The request passed to MPI_WAIT may not have a buffer associated >> with it. MPI has lots of types of requests, not just non-blocking >> point-to-point communication requests. >> >> 3. Other flavors of MPI_WAIT take arrays of requests (e.g., >> MPI_WAITALL). We'd have to pass an array of buffers corresponding to >> the array of requests, which would just be plain icky (would you have >> to have an array of fortran pointers to refer to all the requisite >> buffers?). > > This is what Fortran generic interfaces, or optional arguments, are for. > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

1 0