June 2012 - mpi-forum - mailman3.cels.anl.gov

Tickets into approved SVN and their new Fortran bindings
by Rolf Rabenseifner 30 Jun '12

30 Jun '12

Dear all chapter authors, this email is important for you, because it tells how to add the new mpif08 Fortran bindings into your tex files. When you include your passed tickets' latex with new routines into the approved/MPI-3.0 SVN, then the new Fortran binding for these new routines is typically still missing. You work on chap-xxx/xxx.tex (which maybe, e.g., chap-pt2pt/pt2pt.tex) To add the new mpif08 bindings, you have to do: - Go into your SVN approved/MPI-3.0 directory cd <whereever its is on your system>approved/MPI-3.0/ - Do not go into any subdirectory - Commit your changes before adding the mpif08 bindings: svn ci chap-xxx/xxx.tex -m 'Ticket nnn in chap-xxx added, but without new mpif08 bindings' - CAUTION: Your chap-xxx/xxx.tex must have fileformat=unix and ***not*** fileformat=dos! Check with file chap-xxx/xxx.tex It must report chap-xxx/xxx.tex: ASCII text It must ***not** report chap-xxx/xxx.tex: ASCII text, with CRLF line terminators - In this case: vi chap-xxx/xxx.tex :set fileformat=unix :wq helps. - The next steps will add the new mpif08 Fortran bindings to your newly included ticket: cp -p chap-xxx/xxx.tex chap-xxx/xxx_OLD.tex ./ADD-F2008-for-one-chapter.sh chap-xxx/xxx.tex You may check whats new: diff chap-xxx/xxx_OLD.tex chap-xxx/xxx.tex The only changes should be the addition of the mpifnewbind lines! - Commit the result: svn ci chap-xxx/xxx.tex -m 'Ticket nnn in chap-xxx complete with new mpif08 bindings' IMPORTANT: - Never change any \mpifnewbind{...} or \mpifnewnonebind{...} line. With the next run of ./ADD-F2008-for-one-chapter.sh, all your manual changes are lost. - Never add any \mpifnewbind{...} or \mpifnewnonebind{...} line by hand. It should be done always by this script. Background: - ./ADD-F2008-for-one-chapter.sh works with a sed script ./ADD-F2008.sed This script corresponds to a set of files which can be directly used to define the new mpif08 module. - I'll store these files also in the SVN in the next days. Scope: - The script is prepared for all possible MPI-3.0 tickets: - Already passed tickets: - and already included in the Fortran ticket #229: #38 #109 #219 #258 #265 #270 #274 #284 #299 - and newly provided now, see also Annex B.2 for checking: #168 #204 #280 #286 #287 - Current status Had 1st Vote: - and newly provided now, see also Annex B.2 for checking: #271 - All other tickets do not provide new MPI routines with Fortran bindings. 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: [Mpi-forum] C++ issues
by N.M. Maclaren 29 Jun '12

29 Jun '12

On Jun 29 2012, Jeff Squyres wrote: >> >> I don't think that I did, but it is a real issue. It is undefined >> behaviour of the worst kind to throw a C++ exception where there is a >> Fortran procedure in the call chain between the throw and the catch, and >> undefined behaviour of a seriously nasty kind when there is a C one. > > So are you saying that even MPI::ERRORS_THROW_EXCEPTIONS was a bad idea? > (Given that most [all?] MPI implementations are written in C) No. The point there is that (as with the Fortran), the implementation code has to follow the conventions of the interface language, which may or may not involve some arcane hacking. I was referring specifically to user code in the call chain. > If we keep some form of MPI*ERRORS_THROW_EXCEPTIONS, perhaps we should > add some possibility of it not being usable (e.g., for configurations > where you can't safely throw a C++ exception through intermediate C > code), like making MPI_ERRORS_THROW_EXCEPTIONS == MPI_ERRHANDLER_NULL, or > some such...? Agreed. And the specification should state that it is implementation- dependent. Personally, given the decision to drop C++, I would take a very hard line on this C++-only facility. It's certainly the cleanest and easiest solution. Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] C++ issues
by Jeff Squyres 29 Jun '12

29 Jun '12

On Jun 29, 2012, at 8:17 AM, N.M. Maclaren wrote: > I don't think that I did, but it is a real issue. It is undefined behaviour > of the worst kind to throw a C++ exception where there is a Fortran > procedure in the call chain between the throw and the catch, and undefined > behaviour of a seriously nasty kind when there is a C one. So are you saying that even MPI::ERRORS_THROW_EXCEPTIONS was a bad idea? (Given that most [all?] MPI implementations are written in C) > This has two consequences: > > 1) You can't replace MPI_ERRORS_THROW_EXCEPTIONS by a user-written > hander, and > > 2) You can't define MPI_ERRORS_THROW_EXCEPTIONS in even vaguely > standard C or Fortran using user-written handlers. > > Sorry, but that should be terminated with maximum prejudice. It always > was well-defined only for pure C++ code. > > [ The reason that it applies to C intermediates as well is that the C > code may break the data structures used for the C++ stack unwinding. > Most CURRENT compilers won't, but I have used ones that did, and it > may well happen if you mix C and C++ compilers from different vendors, > even today. ] If we keep some form of MPI*ERRORS_THROW_EXCEPTIONS, perhaps we should add some possibility of it not being usable (e.g., for configurations where you can't safely throw a C++ exception through intermediate C code), like making MPI_ERRORS_THROW_EXCEPTIONS == MPI_ERRHANDLER_NULL, or some such...? -- 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: [Mpi-forum] C++ issues
by N.M. Maclaren 29 Jun '12

29 Jun '12

On Jun 29 2012, Jeff Squyres wrote: > > 2. I have a dim recollection of someone saying that you can't always > replace MPI::ERRORS_THROW_EXCEPTIONS with a user-defined error handler > that throws an exception. Aside from the fact that MPI implementations > need to ensure that they can transparently pass exceptions (e.g., compile > a C-based MPI implementation with > --allow-passing-cxx-exceptions-through-c-functions types of compiler > flags), is my faulty memory remembering a real issue? I have a dim > recollection that it may have been Darius or Dave G. who brought up this > issue...? > >If this is a real issue, do we need to provide MPI_ERRORS_THROW_EXCEPTIONS? I don't think that I did, but it is a real issue. It is undefined behaviour of the worst kind to throw a C++ exception where there is a Fortran procedure in the call chain between the throw and the catch, and undefined behaviour of a seriously nasty kind when there is a C one. This has two consequences: 1) You can't replace MPI_ERRORS_THROW_EXCEPTIONS by a user-written hander, and 2) You can't define MPI_ERRORS_THROW_EXCEPTIONS in even vaguely standard C or Fortran using user-written handlers. Sorry, but that should be terminated with maximum prejudice. It always was well-defined only for pure C++ code. [ The reason that it applies to C intermediates as well is that the C code may break the data structures used for the C++ stack unwinding. Most CURRENT compilers won't, but I have used ones that did, and it may well happen if you mix C and C++ compilers from different vendors, even today. ] Regards, Nick Maclaren.

1 0

C++ issues
by Jeff Squyres 29 Jun '12

29 Jun '12

1. For those of you who missed it, please note that Rolf has made a very important MPI-2.2 errata proposal regarding supporting C++ datatypes: http://lists.mpi-forum.org/mpi-forum/2012/06/1848.php Note that I agree that this is was actually an error: we just previously goofed by not listing some of the MPI:: datatypes with MPI_ language-neutral equivalents. Nevertheless, this is important and everyone should realize that this is being proposed as a *single-vote MPI-2.2 errata*. It has implications on most (all?) existing MPI implementations. *** SUPPORTING RATIONALE: Some users have pointed out (rightfully, IMNSHO) that if we're deleting the C++ bindings in MPI-3 #281, we need to ensure to still support C++ datatypes with the C bindings. Hence, Rolf's MPI-2.2 errata proposal is pretty important. *** Doug/Rolf: there *may* be some side-effects of Rolf's proposal on #281 (e.g., leaving some language about C++-specific datatypes in, even if they get changed from MPI::<foo> to MPI_CXX_<foo>). #281 and Rolf's proposal should be examined together to ensure that they don't conflict in areas like this. 2. I have a dim recollection of someone saying that you can't always replace MPI::ERRORS_THROW_EXCEPTIONS with a user-defined error handler that throws an exception. Aside from the fact that MPI implementations need to ensure that they can transparently pass exceptions (e.g., compile a C-based MPI implementation with --allow-passing-cxx-exceptions-through-c-functions types of compiler flags), is my faulty memory remembering a real issue? I have a dim recollection that it may have been Darius or Dave G. who brought up this issue...? If this is a real issue, do we need to provide MPI_ERRORS_THROW_EXCEPTIONS? -- 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: [Mpi-forum] C++ types inaccessible after #281
by Jeff Squyres 28 Jun '12

28 Jun '12

On Jun 28, 2012, at 2:28 AM, Rolf Rabenseifner wrote: > There is obviously one exception: The middle table on page 517, > because we forgot to define the handles for the 4 C++ types > in the other language bindings (C, Fortran). > > I would propose to fill the gap by > - defining in C and Fortran MPI_CPP_BOOL for C++ bool > - defining in C and Fortran MPI_CPP_COMPLEX, > MPI_CPP_DOUBLE_COMPLEX, MPI_CPP_LONG_DOUBLE_COMPLEX, [snip] All of the rest of this sounds find to me, except that I would marginally prefer MPI_CXX_BOOL, MPI_CXX_COMPLEX, ...etc. (i.e., CXX instead of CPP). "CPP" is a bit overloaded; it can also mean the "C Pre Processor" (e.g., in Make/shell variable parlance). -- 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: [Mpi-forum] C++ types inaccessible after #281
by N.M. Maclaren 28 Jun '12

28 Jun '12

I am putting various responses together, for clarity. On Jun 27 2012, Marc Snir wrote: > > The standard does not say much about datatypes that do not correspond to > primitive datatypes of the host language. I would suggest that is we > define an MPI_Complex type for a language that that does not have a > primitive complex, then the implementation will decide how it defines a > complex (e.g., two successive doubles) and perform reductions > accordingly. A good quality implementation will make C++/C interaction > easier. That assumes that there is only one, and there may not be. Inter alia, complex IS a primitive datatype in Fortran, but not in C+, and only sort-of in C. On Jun 28 2012, Rolf Rabenseifner wrote: > >I would propose to fill the gap by >- defining in C and Fortran MPI_CPP_BOOL for C++ bool >- defining in C and Fortran MPI_CPP_COMPLEX, > MPI_CPP_DOUBLE_COMPLEX, MPI_CPP_LONG_DOUBLE_COMPLEX, Yes. That would fix the problem. > if the C/C++ standards do not require that > C "... _Complex" and C++ "Complex<...>" is internally > implemented in an identical way, They don't. >To be decided by the C/C++ specialists: > - Is MPI_CPP_..._COMPLEX needed or is MPI_C_..._COMPLEX > enough for C++? > - If MPI_CPP_..._COMPLEX is needed, what are the external 32 > sizes? > (I expect, it's external32 and therefore same as for C.) > - Which is the external32 size for MPI_CPP_BOOL? The former, certainly - as others have said, the representation will almost always be the same. C++ bool is not required to be one byte, and its representation is unspecified, but will almost always be one byte and 1. >To be decided by the whole Forum: > - Do we make this MPI-2.2 errata to help the C++ > programmer using the MPI C language binding? Speaking for my users, yes, please! >> On Jun 27, 2012, at 3:10 PM, Jeff Squyres wrote: >> >> > Don't forget a few points: >> > >> > - As Jim pointed out, all MPI datatypes are supposed to be available >> > in all language bindings. Hence, if we have (for example) >> > MPI_CXX_COMPLEX, it needs to be available in both C and the various >> > Fortran bindings. >> > >> > - This is not as wonky as it sounds; With Fortran's C interoperability, it's not at all wonky, and an increasing number of Fortran+C programs are doing it. >> > - That being said, handling reductions on MPI_CXX_COMPLEX from >> > C-based MPI implementations may be a little problematic if the types >> > are not equivalent between C and C++, for example... Yes, that's the only issue that needs more than the representation. In all cases, it may be necessary to call into the owning language to do the reduction. Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] C++ types inaccessible after #281
by Rolf Rabenseifner 28 Jun '12

28 Jun '12

> The standard does not say much about datatypes that do not correspond > to primitive datatypes of the host language. I'm not sure, what you mean with "host language". MPI-2.2 p503:7-8 clearly states: "All predefined datatypes can be used in datatype constructors in any language." Tables on p516-518 define all MPI predefined datatype handles for C and Fortran types both in the MPI C, the MPI Fortran and the MPI C++ binding. There is obviously one exception: The middle table on page 517, because we forgot to define the handles for the 4 C++ types in the other language bindings (C, Fortran). I would propose to fill the gap by - defining in C and Fortran MPI_CPP_BOOL for C++ bool - defining in C and Fortran MPI_CPP_COMPLEX, MPI_CPP_DOUBLE_COMPLEX, MPI_CPP_LONG_DOUBLE_COMPLEX, if the C/C++ standards do not require that C "... _Complex" and C++ "Complex<...>" is internally implemented in an identical way, and otherwise adding in the table on page 516 - "C++ Complex<float>" after "float _Complex" - "C++ Complex<double>" after "double _Complex" - "C++ Complex<long double>" after "long double _Complex" - The "new" datatypes MPI_CPP_BOOL, and perhaps MPI_CPP_COMPLEX, MPI_CPP_DOUBLE_COMPLEX, MPI_CPP_LONG_DOUBLE_COMPLEX, must be also mentioned in Table 13.2, on page 433. This was also overseen since MPI-2.0. Based on the clear statement on MPI-2.2 p503:7-8 "All predefined datatypes can be used in datatype constructors in any language., I would say this should be a one vote MPI-2.2 errata. As I mentioned in earlier emails, a few MPI-2.2 errata are necessary as errata and not only as a modification in MPI-3.0. The should be also mentioned in the Change-Log. These MPI-2.2 errata tickets are: - Ticket #171 (MPI_C_BOOL has external32 size 1 Byte) - Tickets #166 List-item 1, #192, #202 because they are related to C++ which may be removed in MPI-3.0 due to #281 To be decided by the C/C++ specialists: - Is MPI_CPP_..._COMPLEX needed or is MPI_C_..._COMPLEX enough for C++? - If MPI_CPP_..._COMPLEX is needed, what are the external 32 sizes? (I expect, it's external32 and therefore same as for C.) - Which is the external32 size for MPI_CPP_BOOL? To be decided by the whole Forum: - Do we make this MPI-2.2 errata to help the C++ programmer using the MPI C language binding? Rolf ----- Original Message ----- > From: "Marc Snir" <snir(a)mcs.anl.gov> > To: "Main MPI Forum mailing list" <mpi-forum(a)lists.mpi-forum.org> > Sent: Wednesday, June 27, 2012 11:04:55 PM > Subject: Re: [Mpi-forum] C++ types inaccessible after #281 > The standard does not say much about datatypes that do not correspond > to primitive datatypes of the host language. I would suggest that is > we define an MPI_Complex type for a language that that does not have a > primitive complex, then the implementation will decide how it defines > a complex (e.g., two successive doubles) and perform reductions > accordingly. A good quality implementation will make C++/C interaction > easier. > > On Jun 27, 2012, at 3:10 PM, Jeff Squyres wrote: > > > On Jun 27, 2012, at 3:59 PM, N.M. Maclaren wrote: > > > >> Yes, this is an ungodly mess. I don't agree with the forum's > >> decision, > >> but let's accept it. The only reasonable approach is the one of > >> having > >> MPI types for C++'s types, which could still be used via the C > >> interface > >> from a C++ compiler. I believe that is what you were referring to, > >> and > >> what is intended. > > > > > > Thanks for the excellent summary. > > > > Don't forget a few points: > > > > - As Jim pointed out, all MPI datatypes are supposed to be available > > in all language bindings. Hence, if we have (for example) > > MPI_CXX_COMPLEX, it needs to be available in both C and the various > > Fortran bindings. > > > > - This is not as wonky as it sounds; you may have a C++ MPI process > > send an MPI_CXX_COMPLEX to a Fortran MPI process who simply receives > > that message into a buffer and doesn't try to interpret it. The > > Fortran MPI process could then send that same MPI_CXX_COMPLEX > > process back to a C++ MPI process later, who could then rightfully > > interpret it properly (this example can be made for any > > language-specific type, actually). > > > > - From an MPI implementation's perspective, we don't have to worry > > too much about the behavior and semantics of a given type -- we > > mainly only have to worry about the byte layout in memory. Hence, > > getting the size of a given type (and sometimes its alignment) is > > all that is necessary for a C-based MPI implementation to be able to > > properly pack/unpack/send/receive MPI_CXX_COMPLEX. (right?) > > > > - That being said, handling reductions on MPI_CXX_COMPLEX from > > C-based MPI implementations may be a little problematic if the types > > are not equivalent between C and C++, for example... > > > > -- > > Jeff Squyres > > jsquyres(a)cisco.com > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- 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: [Mpi-forum] C++ types inaccessible after #281
by Marc Snir 27 Jun '12

27 Jun '12

The standard does not say much about datatypes that do not correspond to primitive datatypes of the host language. I would suggest that is we define an MPI_Complex type for a language that that does not have a primitive complex, then the implementation will decide how it defines a complex (e.g., two successive doubles) and perform reductions accordingly. A good quality implementation will make C++/C interaction easier. On Jun 27, 2012, at 3:10 PM, Jeff Squyres wrote: > On Jun 27, 2012, at 3:59 PM, N.M. Maclaren wrote: > >> Yes, this is an ungodly mess. I don't agree with the forum's decision, >> but let's accept it. The only reasonable approach is the one of having >> MPI types for C++'s types, which could still be used via the C interface >> from a C++ compiler. I believe that is what you were referring to, and >> what is intended. > > > Thanks for the excellent summary. > > Don't forget a few points: > > - As Jim pointed out, all MPI datatypes are supposed to be available in all language bindings. Hence, if we have (for example) MPI_CXX_COMPLEX, it needs to be available in both C and the various Fortran bindings. > > - This is not as wonky as it sounds; you may have a C++ MPI process send an MPI_CXX_COMPLEX to a Fortran MPI process who simply receives that message into a buffer and doesn't try to interpret it. The Fortran MPI process could then send that same MPI_CXX_COMPLEX process back to a C++ MPI process later, who could then rightfully interpret it properly (this example can be made for any language-specific type, actually). > > - From an MPI implementation's perspective, we don't have to worry too much about the behavior and semantics of a given type -- we mainly only have to worry about the byte layout in memory. Hence, getting the size of a given type (and sometimes its alignment) is all that is necessary for a C-based MPI implementation to be able to properly pack/unpack/send/receive MPI_CXX_COMPLEX. (right?) > > - That being said, handling reductions on MPI_CXX_COMPLEX from C-based MPI implementations may be a little problematic if the types are not equivalent between C and C++, for example... > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

Re: [Mpi-forum] C++ types inaccessible after #281
by Jed Brown 27 Jun '12

27 Jun '12

On Wed, Jun 27, 2012 at 11:59 AM, N.M. Maclaren <nmm1(a)cam.ac.uk> wrote: > It's not the compiler that is the issue, because MPI needs only the C > facilities that are available in the C subset of C++. > But C (90 or otherwise) isn't a subset of C++, though I don't see it being relevant. > It's what is defined > in the various standards. > > I was hoping to get time to respond in a more carefully thought-out > message, > but am in a WG5 meeting, so this is in haste. > > Using C99 is NOT a solution, largely because the requirement is for use > from C++ and std::complex and std::bool do not have equivalents in C99 > (_Complex ,and _Bool are semantically different, and are not required to > match those. > So in C++ sizeof(bool) is not required to be 1. It's not clear to me whether the integer rank inequalities in C99 require it to be equal to 1 (like char). In either case, there is no guarantee that these have the same size, thus we seem to need a MPI_CXX_BOOL for completeness (though no science will ever be impeded by lack of support for bool). It is certainly the case that C99 _Complex has the same data representation as the corresponding std::complex type, cf. C99 6.2.5.13 and C++11 26.4 paragraph 4. Note that MPI does not care about differences in conversion semantics that account for the most commonly encountered incompatibilities between C99 and C++ types. > Also, the required language is C90, because C++03 inherits > from it, and C99 has been rejected (for VERY good reasons) by about half > of the C-using communities. > > While C++11 nominally inherits from C99, it has not included _Complex or > _Bool, and has kept a lot of C90 semantics in cases where C99 and C90 are > incompatible. Most of those don't affect this, but one aspect does. > > Someone mentioned that C99 _Complex has better semantics than std::complex. > I am afraid that is the converse of the truth, especially when you bring > in the utterly appalling Annex G. > What is the problem with Annex G (which is not normative)? C++ doesn't specify anything in particular, nor even suggest that division ought to be implemented in a stable way. > C++11 has included the function calls > for IEEE 754 support, but neither the pragmas nor the semantics, and the > combination is therefore totally undefined. > Sure, so C99 semantics conform to C++ requirements because C++ doesn't bother specifying anything. > > Yes, this is an ungodly mess. I don't agree with the forum's decision, > but let's accept it. The only reasonable approach is the one of having > MPI types for C++'s types, which could still be used via the C interface > from a C++ compiler. I believe that is what you were referring to, and > what is intended. > As in my first email, I think that MPI_CXX_COMPLEX et al should be defined, but I haven't seen anything to indicate that an implementation would not be able to simply make them aliases to MPI_C_COMPLEX.

1 0