- Mpi-21 - mailman3.cels.anl.gov

Re: [Mpi-21] MPI-2.1: Fortran 90 bindings
by unknown＠example.com 06 Mar '08

06 Mar '08

Good points; accepted as friendly amendments [to my as-yet nonexistent proposal :-) ]. On Mar 6, 2008, at 9:03 AM, Richard Treumann wrote: > Jeff - > > The statement in the standard should allow an MPI implementation the > option of leaving out checking for MPI functions with single or > double CHOICE buffers but should not say they "are explicitly not > included in the F90 bindings.". > > It is possible that even 5,250 functions would be a problem on some > Fortran compilers and an implementation that has to deal with such a > compiler may wish to provide checking for the MPI subroutines that > do not have any CHOICE arguments but skip even the 5250 functions > for single CHOICE. > > Some Fortran compilers have non-standard features that allow a > formal parameter to be declared as what amounts to void* and with > that compile feature, CHOICE becomes easy. An MPI implementation > that is based on a Fortran compiler with this feature could check > even double CHOICE easily. > > Dick > > Dick Treumann - MPI Team/TCEM > IBM Systems & Technology Group > Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > mpi-21-bounces_at_[hidden] wrote on 03/05/2008 09:15:35 PM: > > > The current MPI-2 F90 bindings are un-implementable because they > > require almost 7 *million* interface functions: with 15 intrinsic > > Fortran types, each with 7 possible dimensions, the current F90 > > interface *requires*: > > > > - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 > functions > > - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M > > functions > > - ...and a few hundred more MPI functions with no choice buffers > > > > This is clearly broken. > > > > An MPI-2.1-worthy solution could be to add a global statement saying > > that MPI functions with two choice buffers are explicitly not > included > > in the F90 bindings. F90 MPI applications can transparently fall > back > > to the F77 bindings (although they won't get the strong type > checking, > > etc.). This idea therefore fits the requirement of not breaking any > > existing MPI codes. > > > > Specifically: if we remove the requirement to provide all MPI > > functions with two choice buffers, 5,000+ F90 interface functions is > > [a pain but] implementable. I doubt that any current MPI > > implementation provides more than the no-choice-buffers plus one- > > choice-buffer functions anyway... > > > > If this seems like a good idea, I can write a proper proposal for > it. > > Comments? > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > mpi-21 mailing list > > mpi-21_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] MPI-2.1: Fortran 90 bindings
by unknown＠example.com 06 Mar '08

06 Mar '08

Jeff - The statement in the standard should allow an MPI implementation the option of leaving out checking for MPI functions with single or double CHOICE buffers but should not say they "are explicitly not included in the F90 bindings.". It is possible that even 5,250 functions would be a problem on some Fortran compilers and an implementation that has to deal with such a compiler may wish to provide checking for the MPI subroutines that do not have any CHOICE arguments but skip even the 5250 functions for single CHOICE. Some Fortran compilers have non-standard features that allow a formal parameter to be declared as what amounts to void* and with that compile feature, CHOICE becomes easy. An MPI implementation that is based on a Fortran compiler with this feature could check even double CHOICE easily. Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 03/05/2008 09:15:35 PM: > The current MPI-2 F90 bindings are un-implementable because they > require almost 7 *million* interface functions: with 15 intrinsic > Fortran types, each with 7 possible dimensions, the current F90 > interface *requires*: > > - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions > - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M > functions > - ...and a few hundred more MPI functions with no choice buffers > > This is clearly broken. > > An MPI-2.1-worthy solution could be to add a global statement saying > that MPI functions with two choice buffers are explicitly not included > in the F90 bindings. F90 MPI applications can transparently fall back > to the F77 bindings (although they won't get the strong type checking, > etc.). This idea therefore fits the requirement of not breaking any > existing MPI codes. > > Specifically: if we remove the requirement to provide all MPI > functions with two choice buffers, 5,000+ F90 interface functions is > [a pain but] implementable. I doubt that any current MPI > implementation provides more than the no-choice-buffers plus one- > choice-buffer functions anyway... > > If this seems like a good idea, I can write a proper proposal for it. > Comments? > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 *

1 0

Re: [Mpi-21] [MPI3 Fortran] MPI-2.1: Fortran 90 bindings
by unknown＠example.com 06 Mar '08

06 Mar '08

Yes, this is the direction we are going for new Fortran bindings in MPI-3. My proposal is specifically for a small/incremental fix for MPI-2.1's existing MPI F90 bindings. The rule for MPI-2.1 is that changes cannot break existing MPI codes. As such, only "small" things are going into MPI-2.1. On Mar 6, 2008, at 8:25 AM, Lionel, Steve wrote: > I would recommend that for buffers of variable type and rank that the > Fortran interface make use of the Fortran 2003 C interoperability > features, supported by many compilers already, and make these > arguments > of type C_PTR passed by value. The programmer would then pass > C_LOC(buffer), where buffer can be of any type and rank. This is all > specifiable with standard-conforming syntax. > > If this is done, you don't need to have multiple interfaces just to > change type, and you're not giving up any type checking that you would > have had before, as any combination of type and rank would have > matched > some interface. Now you can have as many of these "variant" > arguments as > you like without a mind-numbing series of specific interfaces. > > A compiler using this choice must support the following Fortran 2003 > features: > - Intrinsic module ISO_C_BINDING > - The VALUE attribute > - The BIND(C) attribute > > And if the user chooses a compiler that does not support this, then > they > can use the F77 interfaces. > > Steve Lionel > Developer Products Division > Intel Corporation > Nashua, NH > > > > -----Original Message----- > From: mpi3-fortran-bounces_at_[hidden] > [mailto:mpi3-fortran-bounces_at_[hidden]] On Behalf Of Jeff > Squyres > Sent: Wednesday, March 05, 2008 9:16 PM > To: Mailing list for discussion of MPI 2.1 > Cc: MPI-3 Fortran working group > Subject: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings > Importance: Low > > The current MPI-2 F90 bindings are un-implementable because they > require almost 7 *million* interface functions: with 15 intrinsic > Fortran types, each with 7 possible dimensions, the current F90 > interface *requires*: > > - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 > functions > - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M > functions > - ...and a few hundred more MPI functions with no choice buffers > > This is clearly broken. > > An MPI-2.1-worthy solution could be to add a global statement saying > that MPI functions with two choice buffers are explicitly not included > in the F90 bindings. F90 MPI applications can transparently fall back > to the F77 bindings (although they won't get the strong type checking, > etc.). This idea therefore fits the requirement of not breaking any > existing MPI codes. > > Specifically: if we remove the requirement to provide all MPI > functions with two choice buffers, 5,000+ F90 interface functions is > [a pain but] implementable. I doubt that any current MPI > implementation provides more than the no-choice-buffers plus one- > choice-buffer functions anyway... > > If this seems like a good idea, I can write a proper proposal for it. > Comments? > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] [MPI3 Fortran] MPI-2.1: Fortran 90 bindings
by unknown＠example.com 06 Mar '08

06 Mar '08

I would recommend that for buffers of variable type and rank that the Fortran interface make use of the Fortran 2003 C interoperability features, supported by many compilers already, and make these arguments of type C_PTR passed by value. The programmer would then pass C_LOC(buffer), where buffer can be of any type and rank. This is all specifiable with standard-conforming syntax. If this is done, you don't need to have multiple interfaces just to change type, and you're not giving up any type checking that you would have had before, as any combination of type and rank would have matched some interface. Now you can have as many of these "variant" arguments as you like without a mind-numbing series of specific interfaces. A compiler using this choice must support the following Fortran 2003 features: - Intrinsic module ISO_C_BINDING - The VALUE attribute - The BIND(C) attribute And if the user chooses a compiler that does not support this, then they can use the F77 interfaces. Steve Lionel Developer Products Division Intel Corporation Nashua, NH -----Original Message----- From: mpi3-fortran-bounces_at_[hidden] [mailto:mpi3-fortran-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Wednesday, March 05, 2008 9:16 PM To: Mailing list for discussion of MPI 2.1 Cc: MPI-3 Fortran working group Subject: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings Importance: Low The current MPI-2 F90 bindings are un-implementable because they require almost 7 *million* interface functions: with 15 intrinsic Fortran types, each with 7 possible dimensions, the current F90 interface *requires*: - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M functions - ...and a few hundred more MPI functions with no choice buffers This is clearly broken. An MPI-2.1-worthy solution could be to add a global statement saying that MPI functions with two choice buffers are explicitly not included in the F90 bindings. F90 MPI applications can transparently fall back to the F77 bindings (although they won't get the strong type checking, etc.). This idea therefore fits the requirement of not breaking any existing MPI codes. Specifically: if we remove the requirement to provide all MPI functions with two choice buffers, 5,000+ F90 interface functions is [a pain but] implementable. I doubt that any current MPI implementation provides more than the no-choice-buffers plus one- choice-buffer functions anyway... If this seems like a good idea, I can write a proper proposal for it. Comments? -- Jeff Squyres Cisco Systems _______________________________________________ mpi3-fortran mailing list mpi3-fortran_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

1 0

Re: [Mpi-21] Review of MPI-2.1 combined document
by unknown＠example.com 06 Mar '08

06 Mar '08

On Mar 5, 2008, at 10:05 PM, Jeff Squyres wrote: > - I see a few EXAMPLES items in the index. But this is clearly not > *all* the examples. What's the intent for these items? ...ditto for the typedefs at the end of the index. -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] Review of MPI-2.1 combined document
by unknown＠example.com 06 Mar '08

06 Mar '08

Rolf -- This is *most* helpful. Thanks! On Mar 6, 2008, at 4:08 AM, Rolf Rabenseifner wrote: > Dear all MPI-2.1 reviewer, > > I have produced an additional mpi-report-2.1draft-2008-03-06-blue.pdf > on doc (via http://www.hlrs.de/mpi/mpi21/ ) > > There, all MPI-2.0 is blue. New text is still red. > Content is the same as Feb. 23, 2008. > > For all who have already printed: > The red parts in MPI-2.1 Versions Feb 28 and blue March 06, 2008 > are on (page/line): > i, > ii, > iii, > xiv/11, > xv/7, > (xvii is printed red without reason - it is unmodified 2.0), > (some references are printed red without reason!) > xviii, > 4/38-46, > 5/30-33, > 5/46 - sorry, is not red, but new! > 79/43-44, > 82/47-48, > 85/10-11, > 93/43-44, > 95/32-33, > 98/3, > 99/1-2 - sorry, is not red, but new! > 99/15-16, > (152/1-3 is printed red without reason - it is unmodified 1.1), > 152/38-153/6 - is the MPI-1.2 correction MPI-2.0 Sect.3.2.7 that we > discussed and modified at Jan.2008 meeting. > 215/29-30, > 217/28-29, > 218/17-18, > 219/20-21, > 220/20-21, > 248/2-3, > 254/29-30, > 255/39-40, > 256/21-22, > 258/28, > 262/18-19, > 465/30-31. > > That's all!. > > Important is also the removed text! > You can find it at > http://www.hlrs.de/mpi/mpi21/doc/removed_sources.tex > > As reviewer, you should check, whether the removed text in your > chapter > must or should be really removed! > > Best regards > Rolf > > > On Wed, 5 Mar 2008 21:04:40 -0500 > Jeff Squyres <jsquyres_at_[hidden]> wrote: >> On Feb 23, 2008, at 4:19 PM, Rolf Rabenseifner wrote: >> >>> Dear reviewer: >>> Please print your chapter with colors (!) and check all merging >>> decisions. >>> The colors will help to identify MPI 1.1-1.3 (black), >>> MPI-2.0 (magenta) and new text that was necessary for the merge >>> (red). >> >> Is there a way to use different colors, perchance? >> >> The language bindings chapter is all MPI-2 (magenta); it is nearly >> impossible to tell if there is any merge text in it (red). >> >> -- >> Jeff Squyres >> Cisco Systems >> >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > 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) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] MPI-2.1: Fortran 90 bindings
by unknown＠example.com 06 Mar '08

06 Mar '08

On Mar 6, 2008, at 2:51 AM, Luis Kornblueh wrote: > What about providing an ISO_C_BINDING based interface? MPI is not a > game > and programmers doing MPI are usually quite good and capable of > handling > the basic type checking themselfs ... New Fortran bindings are being proposed for MPI-3 (come join the effort; http://meetings.mpi-forum.org/mpi3.0_ftn_bindings.html; there's a teleconf today at 11am US Eastern to continue our discussions -- +1 866-736-2112). But that's not what I'm trying to address here. The problem is that The MPI-2 F90 bindings are broken / unimplementable. I am proposing a small, incremental fix for MPI-2.1. -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] Review of MPI-2.1 combined document
by unknown＠example.com 06 Mar '08

06 Mar '08

Dear all MPI-2.1 reviewer, I have produced an additional mpi-report-2.1draft-2008-03-06-blue.pdf on doc (via http://www.hlrs.de/mpi/mpi21/ ) There, all MPI-2.0 is blue. New text is still red. Content is the same as Feb. 23, 2008. For all who have already printed: The red parts in MPI-2.1 Versions Feb 28 and blue March 06, 2008 are on (page/line): i, ii, iii, xiv/11, xv/7, (xvii is printed red without reason - it is unmodified 2.0), (some references are printed red without reason!) xviii, 4/38-46, 5/30-33, 5/46 - sorry, is not red, but new! 79/43-44, 82/47-48, 85/10-11, 93/43-44, 95/32-33, 98/3, 99/1-2 - sorry, is not red, but new! 99/15-16, (152/1-3 is printed red without reason - it is unmodified 1.1), 152/38-153/6 - is the MPI-1.2 correction MPI-2.0 Sect.3.2.7 that we discussed and modified at Jan.2008 meeting. 215/29-30, 217/28-29, 218/17-18, 219/20-21, 220/20-21, 248/2-3, 254/29-30, 255/39-40, 256/21-22, 258/28, 262/18-19, 465/30-31. That's all!. Important is also the removed text! You can find it at http://www.hlrs.de/mpi/mpi21/doc/removed_sources.tex As reviewer, you should check, whether the removed text in your chapter must or should be really removed! Best regards Rolf On Wed, 5 Mar 2008 21:04:40 -0500 Jeff Squyres <jsquyres_at_[hidden]> wrote: >On Feb 23, 2008, at 4:19 PM, Rolf Rabenseifner wrote: > >> Dear reviewer: >> Please print your chapter with colors (!) and check all merging >> decisions. >> The colors will help to identify MPI 1.1-1.3 (black), >> MPI-2.0 (magenta) and new text that was necessary for the merge (red). > >Is there a way to use different colors, perchance? > >The language bindings chapter is all MPI-2 (magenta); it is nearly >impossible to tell if there is any merge text in it (red). > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-21 mailing list >mpi-21_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] 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: [Mpi-21] MPI-2.1: Fortran 90 bindings
by unknown＠example.com 06 Mar '08

06 Mar '08

Well, a remark on that: What about providing an ISO_C_BINDING based interface? MPI is not a game and programmers doing MPI are usually quite good and capable of handling the basic type checking themselfs ... > The current MPI-2 F90 bindings are un-implementable because they > require almost 7 *million* interface functions: with 15 intrinsic > Fortran types, each with 7 possible dimensions, the current F90 > interface *requires*: > > - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions > - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M > functions > - ...and a few hundred more MPI functions with no choice buffers > > This is clearly broken. > > An MPI-2.1-worthy solution could be to add a global statement saying > that MPI functions with two choice buffers are explicitly not included > in the F90 bindings. F90 MPI applications can transparently fall back > to the F77 bindings (although they won't get the strong type checking, > etc.). This idea therefore fits the requirement of not breaking any > existing MPI codes. > > Specifically: if we remove the requirement to provide all MPI > functions with two choice buffers, 5,000+ F90 interface functions is > [a pain but] implementable. I doubt that any current MPI > implementation provides more than the no-choice-buffers plus one- > choice-buffer functions anyway... > > If this seems like a good idea, I can write a proper proposal for it. > Comments? > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 -- \\\\\\ (-0^0-) --------------------------oOO--(_)--OOo----------------------------- Luis Kornblueh Tel. : +49-40-41173289 Max-Planck-Institute for Meteorology Fax. : +49-40-41173298 Bundesstr. 53 D-20146 Hamburg Email: luis.kornblueh_at_[hidden] Federal Republic of Germany

1 0

Re: [Mpi-21] Review of MPI-2.1 combined document
by unknown＠example.com 05 Mar '08

05 Mar '08

On Feb 23, 2008, at 4:19 PM, Rolf Rabenseifner wrote: > The first draft of the combined document MPI 1.x plus MPI 2.0 > is ready for review !!! A few general comments on the document: - I love the new items in the index (constants, typedefs, etc.). Very useful! - I see a few EXAMPLES items in the index. But this is clearly not *all* the examples. What's the intent for these items? - p568 in the index has a whole series of lower-case CONST items in the second column that appear to be mistakes (e.g., column headings and the like). Ditto for both columns on page 565 (first page of the index). It looks like a macro is being mis-used throughout the latex...? - It would be really, Really, REALLY nice if the printed page numbers agreed with the PDF page numbers. :-) E.g., the first page of the index has "565" on the bottom of the page, but my PDF viewer tells me that it's really page 583. - How about adding a list of tables and list of figures to the beginning of the document (after the TOC)? How about possibly a list of examples? (I don't know if that's as trivial to generate as LOF/LOT) - In the credits on pages xvi and xvii, should institutions participating in MPI-2.1 be listed? (I can't remember if we discussed this at the last meeting) I.e., there are organizations contributing to the 2.1 document who are not being given credit (e.g., Cisco :-) ). - page 3: "MPI-2 compliance will mean compliance with all of MPI-2." The statement right above that says "MPI-1 compliance will mean compliance with MPI-1.2.", but the credits (page xviii) cite MPI-1.3 and MPI-2.1. - page 5: I see "MPI-2" are in the wrong font twice (there may be more?). - I still have a problem with the wording in section 2.3 about IN / OUT / INOUT, particularly because in section 2.3 we say that IN/OUT/ INOUT does *not* correspond to language bindings, but section 2.6.4 (pages 21-22) specifically states that IN arguments were made "const" in the C++ bindings. I also still have a problem with the special exception for INOUT. Are these topics covered in a ballot somewhere? (those are on my to-do list to examine; haven't gotten there yet...). -- Jeff Squyres Cisco Systems

1 0