November 2010 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] Preprocessor Constants
by Hal Finkel 28 Nov '10

28 Nov '10

On Wed, 2010-11-24 at 10:46 -0800, Adam T. Moody wrote: > Hi Hal, > Yes, the MISC WG would be a good place for this. > I've collected the text of my proposal, its motivation and some notes from the mailing-list thread on a Wiki page: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ReqPPMacro I welcome additional feedback, and I'll submit a ticket in the near future. -Hal > Ultimately, the full contents for a proposal must be placed in a ticket. > https://svn.mpi-forum.org/trac/mpi-forum-web/report > > There is a standard format for a ticket, as an example, see the layout for > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/45 > > Basically, there are certain sections to be filled in, with the main > portion being a listing of the exact changes to be made. The location > of those changes should also be specified (page and line numbers). For > now, base those changes on the MPI 2.2 standard. > > Feel free to create the ticket yourself. You'll need to register for an > account to post/update tickets (if you don't already have one). > https://svn.mpi-forum.org/trac/mpi-forum-web/register > > Very early on in a proposal, when there is still a lot of discussion, > you may want to postpone the ticket and start the proposal in a wiki > instead. The MISC wiki is here: > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Misc > (I need to move the scalability discussion that is currently there to > another page and replace it with a link from the main page.) > > Either way, it'd be useful to boil down and capture the contents of the > discussion you've had with others on the mailing list. No doubt others > will raise these same questions and suggestions, so it's useful to > include this content in the ticket or wiki page. > -Adam > > > Jeff Squyres wrote: > > >Yes, "Misc" is probably the best bet. > > > >I think that WG is run by Adam Moody of Lawerence Livermore Labs... Adam? > > > > > >On Nov 23, 2010, at 3:04 PM, Hal Finkel wrote: > > > > > > > >>On Mon, 2010-11-22 at 18:51 -0500, Jeff Squyres wrote: > >> > >> > >>>It would be great to see your specific proposal to the MPI-3 Forum. :-) > >>> > >>> > >>> > >>What is the appropriate procedure for this? My best guess is to put it > >>on the wiki under "Miscellaneous Items." > >> > >>-Hal > >> > >> > >> > >>>That's both our way of passing the buck back to you :-), and also ensuring that there is a champion to ensure forward progress of each idea that that someone wants to go into MPI-3. In short: if you want it, either drum up the support and get someone to champion it for you, or champion it yourself. > >>> > >>>(please note: the above is not meant to be a snide remark. There are *many* good ideas that we're trying to get into MPI-3. But there are only so many of us and so many hours in a day. The best way to make sure *your* idea gets in is to champion it yourself). > >>> > >>>As noted in New Orleans, you have a bit of a challenge with this idea in that some vendor MPI implementations do not use wrapper compilers, and therefore may have some difficulty in providing this macro. While we don't mandate specific implementation models in the Forum, we do spend a bit of effort to try to ensure that the standard is implementable in some way in all reasonable environments. My point here is that we already have implementations where this idea is problematic: can you come up with a way/technique for these problematic implementations to implement your idea? > >>> > >>> > >>> > >>>On Nov 18, 2010, at 6:25 PM, Hal Finkel wrote: > >>> > >>> > >>> > >>>>Hello, > >>>> > >>>>Appendix A of the current MPI 3 draft (line 45 of page 545) indicates > >>>>that MPI_VERSION and MPI_SUBVERSION are of type, "const int (or unnamed > >>>>enum)". This text is identical to that of the the MPI 2.2 specfication > >>>>(line 45 of page 523), and it should be changed. As the heading on the > >>>>previous line implies, these should be "preprocessor constants," and > >>>>must not be "const int (or unnamed enum)". I recommend replacing, "const > >>>>int (or unnamed enum)" with "integer literal." > >>>> > >>>>Also, regarding the recommendation I made at the SC'10 BOF, I recommend > >>>>adding the following text after line 19 of page 18 and after line 43 on > >>>>page 18: > >>>>User code may assume that mpi.h is unavailable to the preprocessor > >>>>unless the preprocessor constant _MPI is defined prior to source-file > >>>>processing. > >>>> > >>>>The practical implication is intended to be that wrapper programs such > >>>>as mpicc will, in addition to adding the various include and linker > >>>>flags, also add -D_MPI to the compiler command line. This will allow > >>>>user programs to: > >>>> > >>>>#ifdef _MPI > >>>>#include <mpi.h> > >>>>#endif > >>>> > >>>>in a portable way (analogous to testing for _OMP prior to including > >>>><omp.h> when using OpenMP, for example). If the implementation simply > >>>>documents a set of flags which must be given to the compiler, that set > >>>>of flags can simply be extended to include "-D_MPI". Since many codes > >>>>have optional MPI support, this will allow them to use a common > >>>>preprocessor constant, instead of some codes requiring -DMPI, some > >>>>requiring -D_MPI, some requiring -DUSE_MPI, some requiring -DHAVE_MPI, > >>>>some requiring -DHAVE_MPI_H, etc. > >>>> > >>>>Sincerely, > >>>>Hal > >>>> > >>>> > >>>>_______________________________________________ > >>>>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 > >> > >> > > > > > > > > > > _______________________________________________ > 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] Preprocessor Constants
by Adam T. Moody 24 Nov '10

24 Nov '10

Hi Hal, Yes, the MISC WG would be a good place for this. Ultimately, the full contents for a proposal must be placed in a ticket. https://svn.mpi-forum.org/trac/mpi-forum-web/report There is a standard format for a ticket, as an example, see the layout for https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/45 Basically, there are certain sections to be filled in, with the main portion being a listing of the exact changes to be made. The location of those changes should also be specified (page and line numbers). For now, base those changes on the MPI 2.2 standard. Feel free to create the ticket yourself. You'll need to register for an account to post/update tickets (if you don't already have one). https://svn.mpi-forum.org/trac/mpi-forum-web/register Very early on in a proposal, when there is still a lot of discussion, you may want to postpone the ticket and start the proposal in a wiki instead. The MISC wiki is here: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Misc (I need to move the scalability discussion that is currently there to another page and replace it with a link from the main page.) Either way, it'd be useful to boil down and capture the contents of the discussion you've had with others on the mailing list. No doubt others will raise these same questions and suggestions, so it's useful to include this content in the ticket or wiki page. -Adam Jeff Squyres wrote: >Yes, "Misc" is probably the best bet. > >I think that WG is run by Adam Moody of Lawerence Livermore Labs... Adam? > > >On Nov 23, 2010, at 3:04 PM, Hal Finkel wrote: > > > >>On Mon, 2010-11-22 at 18:51 -0500, Jeff Squyres wrote: >> >> >>>It would be great to see your specific proposal to the MPI-3 Forum. :-) >>> >>> >>> >>What is the appropriate procedure for this? My best guess is to put it >>on the wiki under "Miscellaneous Items." >> >>-Hal >> >> >> >>>That's both our way of passing the buck back to you :-), and also ensuring that there is a champion to ensure forward progress of each idea that that someone wants to go into MPI-3. In short: if you want it, either drum up the support and get someone to champion it for you, or champion it yourself. >>> >>>(please note: the above is not meant to be a snide remark. There are *many* good ideas that we're trying to get into MPI-3. But there are only so many of us and so many hours in a day. The best way to make sure *your* idea gets in is to champion it yourself). >>> >>>As noted in New Orleans, you have a bit of a challenge with this idea in that some vendor MPI implementations do not use wrapper compilers, and therefore may have some difficulty in providing this macro. While we don't mandate specific implementation models in the Forum, we do spend a bit of effort to try to ensure that the standard is implementable in some way in all reasonable environments. My point here is that we already have implementations where this idea is problematic: can you come up with a way/technique for these problematic implementations to implement your idea? >>> >>> >>> >>>On Nov 18, 2010, at 6:25 PM, Hal Finkel wrote: >>> >>> >>> >>>>Hello, >>>> >>>>Appendix A of the current MPI 3 draft (line 45 of page 545) indicates >>>>that MPI_VERSION and MPI_SUBVERSION are of type, "const int (or unnamed >>>>enum)". This text is identical to that of the the MPI 2.2 specfication >>>>(line 45 of page 523), and it should be changed. As the heading on the >>>>previous line implies, these should be "preprocessor constants," and >>>>must not be "const int (or unnamed enum)". I recommend replacing, "const >>>>int (or unnamed enum)" with "integer literal." >>>> >>>>Also, regarding the recommendation I made at the SC'10 BOF, I recommend >>>>adding the following text after line 19 of page 18 and after line 43 on >>>>page 18: >>>>User code may assume that mpi.h is unavailable to the preprocessor >>>>unless the preprocessor constant _MPI is defined prior to source-file >>>>processing. >>>> >>>>The practical implication is intended to be that wrapper programs such >>>>as mpicc will, in addition to adding the various include and linker >>>>flags, also add -D_MPI to the compiler command line. This will allow >>>>user programs to: >>>> >>>>#ifdef _MPI >>>>#include <mpi.h> >>>>#endif >>>> >>>>in a portable way (analogous to testing for _OMP prior to including >>>><omp.h> when using OpenMP, for example). If the implementation simply >>>>documents a set of flags which must be given to the compiler, that set >>>>of flags can simply be extended to include "-D_MPI". Since many codes >>>>have optional MPI support, this will allow them to use a common >>>>preprocessor constant, instead of some codes requiring -DMPI, some >>>>requiring -D_MPI, some requiring -DUSE_MPI, some requiring -DHAVE_MPI, >>>>some requiring -DHAVE_MPI_H, etc. >>>> >>>>Sincerely, >>>>Hal >>>> >>>> >>>>_______________________________________________ >>>>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 >> >> > > > >

1 0

Re: [Mpi-forum] Preprocessor Constants
by Jeff Squyres 24 Nov '10

24 Nov '10

Yes, "Misc" is probably the best bet. I think that WG is run by Adam Moody of Lawerence Livermore Labs... Adam? On Nov 23, 2010, at 3:04 PM, Hal Finkel wrote: > On Mon, 2010-11-22 at 18:51 -0500, Jeff Squyres wrote: >> It would be great to see your specific proposal to the MPI-3 Forum. :-) >> > > What is the appropriate procedure for this? My best guess is to put it > on the wiki under "Miscellaneous Items." > > -Hal > >> That's both our way of passing the buck back to you :-), and also ensuring that there is a champion to ensure forward progress of each idea that that someone wants to go into MPI-3. In short: if you want it, either drum up the support and get someone to champion it for you, or champion it yourself. >> >> (please note: the above is not meant to be a snide remark. There are *many* good ideas that we're trying to get into MPI-3. But there are only so many of us and so many hours in a day. The best way to make sure *your* idea gets in is to champion it yourself). >> >> As noted in New Orleans, you have a bit of a challenge with this idea in that some vendor MPI implementations do not use wrapper compilers, and therefore may have some difficulty in providing this macro. While we don't mandate specific implementation models in the Forum, we do spend a bit of effort to try to ensure that the standard is implementable in some way in all reasonable environments. My point here is that we already have implementations where this idea is problematic: can you come up with a way/technique for these problematic implementations to implement your idea? >> >> >> >> On Nov 18, 2010, at 6:25 PM, Hal Finkel wrote: >> >>> Hello, >>> >>> Appendix A of the current MPI 3 draft (line 45 of page 545) indicates >>> that MPI_VERSION and MPI_SUBVERSION are of type, "const int (or unnamed >>> enum)". This text is identical to that of the the MPI 2.2 specfication >>> (line 45 of page 523), and it should be changed. As the heading on the >>> previous line implies, these should be "preprocessor constants," and >>> must not be "const int (or unnamed enum)". I recommend replacing, "const >>> int (or unnamed enum)" with "integer literal." >>> >>> Also, regarding the recommendation I made at the SC'10 BOF, I recommend >>> adding the following text after line 19 of page 18 and after line 43 on >>> page 18: >>> User code may assume that mpi.h is unavailable to the preprocessor >>> unless the preprocessor constant _MPI is defined prior to source-file >>> processing. >>> >>> The practical implication is intended to be that wrapper programs such >>> as mpicc will, in addition to adding the various include and linker >>> flags, also add -D_MPI to the compiler command line. This will allow >>> user programs to: >>> >>> #ifdef _MPI >>> #include <mpi.h> >>> #endif >>> >>> in a portable way (analogous to testing for _OMP prior to including >>> <omp.h> when using OpenMP, for example). If the implementation simply >>> documents a set of flags which must be given to the compiler, that set >>> of flags can simply be extended to include "-D_MPI". Since many codes >>> have optional MPI support, this will allow them to use a common >>> preprocessor constant, instead of some codes requiring -DMPI, some >>> requiring -D_MPI, some requiring -DUSE_MPI, some requiring -DHAVE_MPI, >>> some requiring -DHAVE_MPI_H, etc. >>> >>> Sincerely, >>> Hal >>> >>> >>> _______________________________________________ >>> 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 -- 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] Preprocessor Constants
by Hal Finkel 23 Nov '10

23 Nov '10

On Mon, 2010-11-22 at 18:51 -0500, Jeff Squyres wrote: > It would be great to see your specific proposal to the MPI-3 Forum. :-) > What is the appropriate procedure for this? My best guess is to put it on the wiki under "Miscellaneous Items." -Hal > That's both our way of passing the buck back to you :-), and also ensuring that there is a champion to ensure forward progress of each idea that that someone wants to go into MPI-3. In short: if you want it, either drum up the support and get someone to champion it for you, or champion it yourself. > > (please note: the above is not meant to be a snide remark. There are *many* good ideas that we're trying to get into MPI-3. But there are only so many of us and so many hours in a day. The best way to make sure *your* idea gets in is to champion it yourself). > > As noted in New Orleans, you have a bit of a challenge with this idea in that some vendor MPI implementations do not use wrapper compilers, and therefore may have some difficulty in providing this macro. While we don't mandate specific implementation models in the Forum, we do spend a bit of effort to try to ensure that the standard is implementable in some way in all reasonable environments. My point here is that we already have implementations where this idea is problematic: can you come up with a way/technique for these problematic implementations to implement your idea? > > > > On Nov 18, 2010, at 6:25 PM, Hal Finkel wrote: > > > Hello, > > > > Appendix A of the current MPI 3 draft (line 45 of page 545) indicates > > that MPI_VERSION and MPI_SUBVERSION are of type, "const int (or unnamed > > enum)". This text is identical to that of the the MPI 2.2 specfication > > (line 45 of page 523), and it should be changed. As the heading on the > > previous line implies, these should be "preprocessor constants," and > > must not be "const int (or unnamed enum)". I recommend replacing, "const > > int (or unnamed enum)" with "integer literal." > > > > Also, regarding the recommendation I made at the SC'10 BOF, I recommend > > adding the following text after line 19 of page 18 and after line 43 on > > page 18: > > User code may assume that mpi.h is unavailable to the preprocessor > > unless the preprocessor constant _MPI is defined prior to source-file > > processing. > > > > The practical implication is intended to be that wrapper programs such > > as mpicc will, in addition to adding the various include and linker > > flags, also add -D_MPI to the compiler command line. This will allow > > user programs to: > > > > #ifdef _MPI > > #include <mpi.h> > > #endif > > > > in a portable way (analogous to testing for _OMP prior to including > > <omp.h> when using OpenMP, for example). If the implementation simply > > documents a set of flags which must be given to the compiler, that set > > of flags can simply be extended to include "-D_MPI". Since many codes > > have optional MPI support, this will allow them to use a common > > preprocessor constant, instead of some codes requiring -DMPI, some > > requiring -D_MPI, some requiring -DUSE_MPI, some requiring -DHAVE_MPI, > > some requiring -DHAVE_MPI_H, etc. > > > > Sincerely, > > Hal > > > > > > _______________________________________________ > > 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] Preprocessor Constants
by N.M. Maclaren 23 Nov '10

23 Nov '10

On Nov 23 2010, Hal Finkel wrote: > >So the Fortran situation is a bit tricky ;) Fortran does have a >conditional combilation scheme, which is not often used (implemented), >and many Fortran compilers (instead) support a C-like preprocessing >scheme, which I believe is not standard. And is problematic. And the formal mechanism may well be dropped by WG5 at some stage. >So Fortran support might look something like this: I suggest just omitting it. It isn't the only thing that has no equivalent for all languages. Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] Preprocessor Constants
by Hal Finkel 23 Nov '10

23 Nov '10

On Tue, 2010-11-23 at 07:26 -0500, Jeff Squyres wrote: > On Nov 23, 2010, at 7:15 AM, Hal Finkel wrote: > > >> Will the preprocessor value be required for fortran? What about cases where the fortran preprocessor is not used? What about when modules are used? > > > > Because the Fortran preprocessor is not always used (or available?), I > > would concentrate on C and C++. Not that the motivation does not carry > > over to Fortran, but I don't see an obvious, portable solution that > > works for Fortran. > > FWIW... Fortran is always the stickler. I would think that whatever solution is available on the C side should also be available on the Fortran side (when possible). > So the Fortran situation is a bit tricky ;) Fortran does have a conditional combilation scheme, which is not often used (implemented), and many Fortran compilers (instead) support a C-like preprocessing scheme, which I believe is not standard. http://gcc.gnu.org/onlinedocs/gfortran/Preprocessing-and-conditional-compil… says: While CPP is the de-facto standard for preprocessing Fortran code, Part 3 of the Fortran 95 standard (ISO/IEC 1539-3:1998) defines Conditional Compilation, which is not widely used and not directly supported by the GNU Fortran compiler. You can use the program coco to preprocess such files (http://www.daniellnagle.com/coco.html) So Fortran support might look something like this: On systems supporting <Fortran standard>, Part 3 (Conditional Compilation), user code may assume that the mpi module is unavailable to the compiler unless processed as if associated with a SET file containing: ?? LOGICAL, PARAMETER :: _MPI = .TRUE. Advice to implementers: For consistency with the C and C++ language bindings, when Fortran source is preprocessed with a C-like preprocessor, it is recommended that the macro _MPI be predefined. (end formal working) To make use of the scheme with the standard mechanism, the source file would start with: ?? LOGICAL, PARAMETER :: _MPI = .FALSE. and this would be overridden, in accordance with standard, if MPI is available. Sincerely, Hal

1 0

Re: [Mpi-forum] Preprocessor Constants
by N.M. Maclaren 23 Nov '10

23 Nov '10

On Nov 23 2010, Hal Finkel wrote: > >> Damn Webmail! Sorry - please ignore this grobble - it got pasted in by >> accident, and is not true. I believe that there are such issues, but >> they are more subtle than that. > >Are you concerned that there might be subtle issues with requiring any >predefined macro, with _MPI being in the namespace reserved for the >implementation, or both? Neither. And that got pasted in the wrong place, anyway. I believe that POSIX does effectively require an implementation to predefine macros that are not in standard C, but don't have the time to refresh my memory. In any case, I agree that it's not a problem. And I agree that there is no relevance to Fortran. Whether this scheme is a good idea is less clear, but I don't see any significant problems with it, in practice. Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] Preprocessor Constants
by Jeff Squyres 23 Nov '10

23 Nov '10

On Nov 23, 2010, at 7:15 AM, Hal Finkel wrote: >> Will the preprocessor value be required for fortran? What about cases where the fortran preprocessor is not used? What about when modules are used? > > Because the Fortran preprocessor is not always used (or available?), I > would concentrate on C and C++. Not that the motivation does not carry > over to Fortran, but I don't see an obvious, portable solution that > works for Fortran. FWIW... Fortran is always the stickler. I would think that whatever solution is available on the C side should also be available on the Fortran side (when possible). -- 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] Preprocessor Constants
by Hal Finkel 23 Nov '10

23 Nov '10

On Tue, 2010-11-23 at 06:56 -0500, Jeff Squyres (jsquyres) wrote: > Will the preprocessor value be required for fortran? What about cases where the fortran preprocessor is not used? What about when modules are used? > Because the Fortran preprocessor is not always used (or available?), I would concentrate on C and C++. Not that the motivation does not carry over to Fortran, but I don't see an obvious, portable solution that works for Fortran. Sincerely, Hal > Sent from my PDA. No type good. > > On Nov 23, 2010, at 4:57 AM, "N.M. Maclaren" <nmm1(a)cam.ac.uk> wrote: > > > Damn Webmail! Sorry - please ignore this grobble - it got pasted in by > > accident, and is not true. I believe that there are such issues, but > > they are more subtle than that. > > > >>> 1. An implementation which provides wrapper scripts (i.e. mpicc). These scripts could easily add -D_MPI would prevent the conforming use of POSIX! See: > >> > >> http://www.opengroup.org/onlinepubs/009695399/toc.htm > >> 2.2 The Compilation Environment > >> 2.2.1 POSIX.1 Symbols > > > > Regards, > > Nick. > > > > _______________________________________________ > > 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

1 0

Re: [Mpi-forum] Preprocessor Constants
by Hal Finkel 23 Nov '10

23 Nov '10

On Tue, 2010-11-23 at 09:57 +0000, N.M. Maclaren wrote: > Damn Webmail! Sorry - please ignore this grobble - it got pasted in by > accident, and is not true. I believe that there are such issues, but > they are more subtle than that. > Are you concerned that there might be subtle issues with requiring any predefined macro, with _MPI being in the namespace reserved for the implementation, or both? Sincerely, Hal > >> 1. An implementation which provides wrapper scripts (i.e. mpicc). These > >> scripts could easily add -D_MPI would prevent the conforming use of > >> POSIX! See: > > > >http://www.opengroup.org/onlinepubs/009695399/toc.htm > > 2.2 The Compilation Environment > > 2.2.1 POSIX.1 Symbols > > Regards, > Nick. > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0