November 2015 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPIWG Fortran] ticket 351
by Craig Rasmusen 10 Nov '15

10 Nov '15

Jeff, Welcome to the arcane world of Fortran terminology. Fortunately terms like "processor dependent" are only in the standard and don't (hopefully) leak out into the wild! :-) -craig On Mon, Nov 9, 2015 at 1:03 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > We are diverging. I don't know that this informs the ticket one way or > another. Perhaps others can weigh in. > > On Mon, Nov 9, 2015 at 10:41 AM, Bill Long <longb(a)cray.com> wrote: > >> >> On Nov 9, 2015, at 11:43 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: >> >> > MPI implementations today are remarkably standardized w.r.t. process >> launching such that standard arguments are handled prior to MPI_Init. >> However, there have been times where that was not the case. >> > >> > Can you check what the Cray T3D does w.r.t. arguments passed to the >> host node appearing on the compute nodes? :-) >> >> No T3D’s in service. The more general question is whether vendors >> support a new version of MPI on old hardware for which there is no longer >> Fortran compiler support. If you can’t compile the code that calls the new >> MPI routine, them I’d assume the new routine is not relevant to users of >> the system. >> >> > The purpose of my comment was to cite a hosted MPI implementation, to > tease out the differences between today's common practice and the realm of > possibility. > > >> > >> > More seriously, does Fortran 2008 require that arguments passed to the >> invocation of mpirun (or equivalent) appear at every process in a >> multi-process MPI program? >> > >> >> Well, the Fortran standard says nothing about MPI, as should be the >> case. The method for launching a program is intentionally outside the >> scope of the standard. >> >> However, you make a reasonable point. The current standard has a sentence >> >> "The effects of calling COMMAND_ARGUMENT_COUNT, EXECUTE_COMMAND_LINE , >> GET_COMMAND, GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT_VARIABLE on any >> image other than image 1 are processor dependent.” . >> >> In discussions for the upcoming Fortran 2015 standard, people realized >> this was a silly restriction, and all the routines except >> EXECUTE_COMMAND_LINE were removed from this sentence. Vendors already were >> consistent that command line stuff worked on any image, so the “processor >> dependent” bit was unnecessary. >> >> > What does processor-specific mean? It is specific to the manufacturer, > the ISA, the SKU number, the serial number, ...? I can't even fathom what > sort of terrible thinking lead someone to write such a phrase in a language > standard. > > Why not do what everyone else does and say "implementation-specific"? I > don't even think the behavior is remotely sensitive to the processor. The > support for EXECUTE_COMMAND_LINE is primarily a function of the OS, which > is not a very different thing than a processor. > > Jeff > > >> Cheers, >> Bill >> >> >> >> > Jeff >> > >> > Jeff >> > >> > On Mon, Nov 9, 2015 at 8:56 AM, Bill Long <longb(a)cray.com> wrote: >> > >> > On Nov 9, 2015, at 8:56 AM, Jeff Hammond <jeff.science(a)gmail.com> >> wrote: >> > >> > > >> > > >> > > On Mon, Nov 9, 2015 at 6:37 AM, Bill Long <longb(a)cray.com> wrote: >> > > >> > > On Nov 9, 2015, at 8:24 AM, Jeff Hammond <jeff.science(a)gmail.com> >> wrote: >> > > >> > > > Did you read the ticket? We need this for the same reason >> MPI_Init() takes argc/argv even though C main() already has them. >> > > >> > > But the C standard does not implicitly assume every program is >> parallel. >> > > >> > > >> > > Correct. Nor can MPI assume that argc/argv will magically appear on >> the compute nodes when the job is launched from somewhere else. >> > > >> > >> > Agreed. My point is that Fortran is not the same as C. >> > >> > > > >> > > > While it may be true that process managers are magically fixing >> argc/argv, this is not guaranteed by any standard. >> > > >> > > The Fortran standard is intentionally vague to allow for environments >> where there is no command line, but rather (for example) the code starts >> executing by clicking a graphic button on the screen. The standard is >> likely to not include specific words about program launchers that might >> turn into bit rot in the future. If your favorite compiler returns the >> launcher text as part of the command line, complain. >> > > >> > > >> > > Complaining is fun, but has no teeth without a standard. Many >> vendors are quite strict about standards and reject feature requests that >> improve user experience if they lack justification in a standard. I can >> cite numerous vendors here… >> > >> > The overriding intent of a language standard is portability. You would >> have poor portability of a code if moving it from one machine to another >> resulted in different command argument information from get_command or >> get_command_argument. The intention is that the routine return the command >> line arguments that the program knows about, not some cryptic stuff from >> aprun, srun, or mpirun. I did try all the compilers I have access to on a >> trivial code: >> > >> > > cat test.f90 >> > program test >> > character(1000) command >> > integer length >> > call get_command (command, length) >> > print *, command(1:length) >> > end program test >> > >> > > ftn test.f90 >> > > aprun -n1 ./a.out -x >> > ./a.out -x >> > Application 15961022 resources: utime ~0s, stime ~0s, Rss ~4176, >> inblocks ~4479, outblocks ~11453 >> > > module swap PrgEnv-cray PrgEnv-intel >> > > ftn test.f90 >> > > aprun -n1 ./a.out -x >> > ./a.out -x >> > Application 15961023 resources: utime ~0s, stime ~0s, Rss ~4176, >> inblocks ~2967, outblocks ~7756 >> > > module swap PrgEnv-intel PrgEnv-pgi >> > > ftn test.f90 >> > > aprun -n1 ./a.out -x >> > ./a.out -x >> > Application 15961025 resources: utime ~0s, stime ~0s, Rss ~4172, >> inblocks ~3038, outblocks ~8308 >> > l> module swap PrgEnv-pgi PrgEnv-gnu >> > > ftn test.f90 >> > > aprun -n1 ./a.out -x >> > ./a.out -x >> > Application 15961026 resources: utime ~0s, stime ~0s, Rss ~4172, >> inblocks ~3031, outblocks ~8027 >> > >> > All of them produced the expected output (excluding the “aprun -n1” >> launcher text). >> > >> > Perhaps we could add a Note in the Fortran standard explaining this, >> but it looks like vendors have already figured it out. >> > >> > Cheers, >> > Bill >> > >> > >> > >> > > >> > > While the new proposed routines are trivial to implement (assuming >> they have the same arguments as the corresponding Fortran ones), they add >> to one of MPI’s most serious flaws - way to many routines already. >> > > >> > > >> > > As you say, they are trivial to implement. The size of the standard >> is an irrelevant argument. Users don't read what they don't need to read >> and users shouldn't be reading the spec most of the time anyways. >> > > >> > > Jeff >> > > >> > > Cheers, >> > > Bill >> > > >> > > >> > > > >> > > > Jeff >> > > > >> > > > On Mon, Nov 9, 2015 at 6:21 AM, Bill Long <longb(a)cray.com> wrote: >> > > > Hi Jeff, >> > > > >> > > > I don’t see the value of this. The Fortran intrinsics GET_COMMAND >> and friends should already do what you want. Fortran programs are now >> presumed parallel. The intrinsics should know how to strip off the >> “launcher” part of the command line. At least that is how the Cray >> versions have worked from the beginning. Experiments are in order for >> other vendors, as a check. >> > > > >> > > > Cheers, >> > > > Bill >> > > > >> > > > >> > > > >> > > > On Nov 9, 2015, at 8:13 AM, Jeff Hammond <jeff.science(a)gmail.com> >> wrote: >> > > > >> > > > > we did a lot of work on >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/351. do we intend >> to move forward this for MPI 4+? if yes, we need to migrate the trac >> ticket to a github issue. >> > > > > >> > > > > jeff >> > > > > >> > > > > -- >> > > > > Jeff Hammond >> > > > > jeff.science(a)gmail.com >> > > > > http://jeffhammond.github.io/ >> > > > > _______________________________________________ >> > > > > mpiwg-fortran mailing list >> > > > > mpiwg-fortran(a)lists.mpi-forum.org >> > > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> > > > >> > > > Bill Long >> longb(a)cray.com >> > > > Fortran Technical Support & >> voice: 651-605-9024 >> > > > Bioinformatics Software Development fax: >> 651-605-9142 >> > > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN >> 55101 >> > > > >> > > > >> > > > _______________________________________________ >> > > > mpiwg-fortran mailing list >> > > > mpiwg-fortran(a)lists.mpi-forum.org >> > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> > > > >> > > > >> > > > >> > > > -- >> > > > Jeff Hammond >> > > > jeff.science(a)gmail.com >> > > > http://jeffhammond.github.io/ >> > > > _______________________________________________ >> > > > mpiwg-fortran mailing list >> > > > mpiwg-fortran(a)lists.mpi-forum.org >> > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> > > >> > > Bill Long >> longb(a)cray.com >> > > Fortran Technical Support & voice: >> 651-605-9024 >> > > Bioinformatics Software Development fax: >> 651-605-9142 >> > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 >> > > >> > > >> > > _______________________________________________ >> > > mpiwg-fortran mailing list >> > > mpiwg-fortran(a)lists.mpi-forum.org >> > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> > > >> > > >> > > >> > > -- >> > > Jeff Hammond >> > > jeff.science(a)gmail.com >> > > http://jeffhammond.github.io/ >> > > _______________________________________________ >> > > mpiwg-fortran mailing list >> > > mpiwg-fortran(a)lists.mpi-forum.org >> > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> > >> > Bill Long >> longb(a)cray.com >> > Fortran Technical Support & voice: >> 651-605-9024 >> > Bioinformatics Software Development fax: >> 651-605-9142 >> > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 >> > >> > >> > _______________________________________________ >> > mpiwg-fortran mailing list >> > mpiwg-fortran(a)lists.mpi-forum.org >> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> > >> > >> > >> > -- >> > Jeff Hammond >> > jeff.science(a)gmail.com >> > http://jeffhammond.github.io/ >> > _______________________________________________ >> > mpiwg-fortran mailing list >> > mpiwg-fortran(a)lists.mpi-forum.org >> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> >> Bill Long >> longb(a)cray.com >> Fortran Technical Support & voice: >> 651-605-9024 >> Bioinformatics Software Development fax: >> 651-605-9142 >> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 >> >> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >

1 0

Re: [MPIWG Fortran] ticket 351
by N.M. Maclaren 10 Nov '15

10 Nov '15

On Nov 9 2015, Bill Long wrote: > >However, you make a reasonable point. The current standard has a sentence > > "The effects of calling COMMAND_ARGUMENT_COUNT, EXECUTE_COMMAND_LINE , > GET_COMMAND, GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT_VARIABLE on any > image other than image 1 are processor dependent." . > > In discussions for the upcoming Fortran 2015 standard, people realized > this was a silly restriction, and all the routines except > EXECUTE_COMMAND_LINE were removed from this sentence. Vendors already > were consistent that command line stuff worked on any image, so the > "processor dependent" bit was unnecessary. Sort of. They may all support it, but not all do the same thing. We needed to decide what to specify. Regards, Nick Maclaren.

1 0

Re: [MPIWG Fortran] ticket 351
by N.M. Maclaren 10 Nov '15

10 Nov '15

On Nov 9 2015, Jeff Hammond wrote: >> >What does processor-specific mean? It is specific to the manufacturer, the >ISA, the SKU number, the serial number, ...? I can't even fathom what sort >of terrible thinking lead someone to write such a phrase in a language >standard. > >Why not do what everyone else does and say "implementation-specific"? I >don't even think the behavior is remotely sensitive to the processor. The >support for EXECUTE_COMMAND_LINE is primarily a function of the OS, which >is not a very different thing than a processor. Because Fortran standards predate the C-derived ones by a quarter of a century. Regards, Nick Maclaren.

1 0

Re: [MPIWG Fortran] ticket 351
by Bill Long 09 Nov '15

09 Nov '15

On Nov 9, 2015, at 3:03 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > What does processor-specific mean? It is specific to the manufacturer, the ISA, the SKU number, the serial number, ...? I can't even fathom what sort of terrible thinking lead someone to write such a phrase in a language standard. > > Why not do what everyone else does and say "implementation-specific"? I don't even think the behavior is remotely sensitive to the processor. The support for EXECUTE_COMMAND_LINE is primarily a function of the OS, which is not a very different thing than a processor. Processor and processor dependent are both defined terms in the Fortran standard: • processor combination of a computing system and mechanism by which programs are transformed for use on that computing system • processor dependent not completely specified in this part of ISO/IEC 1539, having methods and semantics determined by the processor So, “processor” includes the compiler, hardware, and OS. Cheers, Bill Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] ticket 351
by Jeff Hammond 09 Nov '15

09 Nov '15

We are diverging. I don't know that this informs the ticket one way or another. Perhaps others can weigh in. On Mon, Nov 9, 2015 at 10:41 AM, Bill Long <longb(a)cray.com> wrote: > > On Nov 9, 2015, at 11:43 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > MPI implementations today are remarkably standardized w.r.t. process > launching such that standard arguments are handled prior to MPI_Init. > However, there have been times where that was not the case. > > > > Can you check what the Cray T3D does w.r.t. arguments passed to the host > node appearing on the compute nodes? :-) > > No T3D’s in service. The more general question is whether vendors support > a new version of MPI on old hardware for which there is no longer Fortran > compiler support. If you can’t compile the code that calls the new MPI > routine, them I’d assume the new routine is not relevant to users of the > system. > > The purpose of my comment was to cite a hosted MPI implementation, to tease out the differences between today's common practice and the realm of possibility. > > > > More seriously, does Fortran 2008 require that arguments passed to the > invocation of mpirun (or equivalent) appear at every process in a > multi-process MPI program? > > > > Well, the Fortran standard says nothing about MPI, as should be the case. > The method for launching a program is intentionally outside the scope of > the standard. > > However, you make a reasonable point. The current standard has a sentence > > "The effects of calling COMMAND_ARGUMENT_COUNT, EXECUTE_COMMAND_LINE , > GET_COMMAND, GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT_VARIABLE on any > image other than image 1 are processor dependent.” . > > In discussions for the upcoming Fortran 2015 standard, people realized > this was a silly restriction, and all the routines except > EXECUTE_COMMAND_LINE were removed from this sentence. Vendors already were > consistent that command line stuff worked on any image, so the “processor > dependent” bit was unnecessary. > > What does processor-specific mean? It is specific to the manufacturer, the ISA, the SKU number, the serial number, ...? I can't even fathom what sort of terrible thinking lead someone to write such a phrase in a language standard. Why not do what everyone else does and say "implementation-specific"? I don't even think the behavior is remotely sensitive to the processor. The support for EXECUTE_COMMAND_LINE is primarily a function of the OS, which is not a very different thing than a processor. Jeff > Cheers, > Bill > > > > > Jeff > > > > Jeff > > > > On Mon, Nov 9, 2015 at 8:56 AM, Bill Long <longb(a)cray.com> wrote: > > > > On Nov 9, 2015, at 8:56 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > > > > > > > > > On Mon, Nov 9, 2015 at 6:37 AM, Bill Long <longb(a)cray.com> wrote: > > > > > > On Nov 9, 2015, at 8:24 AM, Jeff Hammond <jeff.science(a)gmail.com> > wrote: > > > > > > > Did you read the ticket? We need this for the same reason > MPI_Init() takes argc/argv even though C main() already has them. > > > > > > But the C standard does not implicitly assume every program is > parallel. > > > > > > > > > Correct. Nor can MPI assume that argc/argv will magically appear on > the compute nodes when the job is launched from somewhere else. > > > > > > > Agreed. My point is that Fortran is not the same as C. > > > > > > > > > > While it may be true that process managers are magically fixing > argc/argv, this is not guaranteed by any standard. > > > > > > The Fortran standard is intentionally vague to allow for environments > where there is no command line, but rather (for example) the code starts > executing by clicking a graphic button on the screen. The standard is > likely to not include specific words about program launchers that might > turn into bit rot in the future. If your favorite compiler returns the > launcher text as part of the command line, complain. > > > > > > > > > Complaining is fun, but has no teeth without a standard. Many vendors > are quite strict about standards and reject feature requests that improve > user experience if they lack justification in a standard. I can cite > numerous vendors here… > > > > The overriding intent of a language standard is portability. You would > have poor portability of a code if moving it from one machine to another > resulted in different command argument information from get_command or > get_command_argument. The intention is that the routine return the command > line arguments that the program knows about, not some cryptic stuff from > aprun, srun, or mpirun. I did try all the compilers I have access to on a > trivial code: > > > > > cat test.f90 > > program test > > character(1000) command > > integer length > > call get_command (command, length) > > print *, command(1:length) > > end program test > > > > > ftn test.f90 > > > aprun -n1 ./a.out -x > > ./a.out -x > > Application 15961022 resources: utime ~0s, stime ~0s, Rss ~4176, > inblocks ~4479, outblocks ~11453 > > > module swap PrgEnv-cray PrgEnv-intel > > > ftn test.f90 > > > aprun -n1 ./a.out -x > > ./a.out -x > > Application 15961023 resources: utime ~0s, stime ~0s, Rss ~4176, > inblocks ~2967, outblocks ~7756 > > > module swap PrgEnv-intel PrgEnv-pgi > > > ftn test.f90 > > > aprun -n1 ./a.out -x > > ./a.out -x > > Application 15961025 resources: utime ~0s, stime ~0s, Rss ~4172, > inblocks ~3038, outblocks ~8308 > > l> module swap PrgEnv-pgi PrgEnv-gnu > > > ftn test.f90 > > > aprun -n1 ./a.out -x > > ./a.out -x > > Application 15961026 resources: utime ~0s, stime ~0s, Rss ~4172, > inblocks ~3031, outblocks ~8027 > > > > All of them produced the expected output (excluding the “aprun -n1” > launcher text). > > > > Perhaps we could add a Note in the Fortran standard explaining this, but > it looks like vendors have already figured it out. > > > > Cheers, > > Bill > > > > > > > > > > > > While the new proposed routines are trivial to implement (assuming > they have the same arguments as the corresponding Fortran ones), they add > to one of MPI’s most serious flaws - way to many routines already. > > > > > > > > > As you say, they are trivial to implement. The size of the standard > is an irrelevant argument. Users don't read what they don't need to read > and users shouldn't be reading the spec most of the time anyways. > > > > > > Jeff > > > > > > Cheers, > > > Bill > > > > > > > > > > > > > > Jeff > > > > > > > > On Mon, Nov 9, 2015 at 6:21 AM, Bill Long <longb(a)cray.com> wrote: > > > > Hi Jeff, > > > > > > > > I don’t see the value of this. The Fortran intrinsics GET_COMMAND > and friends should already do what you want. Fortran programs are now > presumed parallel. The intrinsics should know how to strip off the > “launcher” part of the command line. At least that is how the Cray > versions have worked from the beginning. Experiments are in order for > other vendors, as a check. > > > > > > > > Cheers, > > > > Bill > > > > > > > > > > > > > > > > On Nov 9, 2015, at 8:13 AM, Jeff Hammond <jeff.science(a)gmail.com> > wrote: > > > > > > > > > we did a lot of work on > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/351. do we intend to > move forward this for MPI 4+? if yes, we need to migrate the trac ticket > to a github issue. > > > > > > > > > > jeff > > > > > > > > > > -- > > > > > Jeff Hammond > > > > > jeff.science(a)gmail.com > > > > > http://jeffhammond.github.io/ > > > > > _______________________________________________ > > > > > mpiwg-fortran mailing list > > > > > mpiwg-fortran(a)lists.mpi-forum.org > > > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > Bill Long > longb(a)cray.com > > > > Fortran Technical Support & > voice: 651-605-9024 > > > > Bioinformatics Software Development fax: > 651-605-9142 > > > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > > > > > > > > > > _______________________________________________ > > > > mpiwg-fortran mailing list > > > > mpiwg-fortran(a)lists.mpi-forum.org > > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > > > > > > > > > -- > > > > Jeff Hammond > > > > jeff.science(a)gmail.com > > > > http://jeffhammond.github.io/ > > > > _______________________________________________ > > > > mpiwg-fortran mailing list > > > > mpiwg-fortran(a)lists.mpi-forum.org > > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > Bill Long > longb(a)cray.com > > > Fortran Technical Support & voice: > 651-605-9024 > > > Bioinformatics Software Development fax: > 651-605-9142 > > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > > > > > > > _______________________________________________ > > > mpiwg-fortran mailing list > > > mpiwg-fortran(a)lists.mpi-forum.org > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > > > > > -- > > > Jeff Hammond > > > jeff.science(a)gmail.com > > > http://jeffhammond.github.io/ > > > _______________________________________________ > > > mpiwg-fortran mailing list > > > mpiwg-fortran(a)lists.mpi-forum.org > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > Bill Long > longb(a)cray.com > > Fortran Technical Support & voice: > 651-605-9024 > > Bioinformatics Software Development fax: > 651-605-9142 > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > > > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > -- > > Jeff Hammond > > jeff.science(a)gmail.com > > http://jeffhammond.github.io/ > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > Bill Long > longb(a)cray.com > Fortran Technical Support & voice: > 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] ticket 351
by Bill Long 09 Nov '15

09 Nov '15

On Nov 9, 2015, at 11:43 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > MPI implementations today are remarkably standardized w.r.t. process launching such that standard arguments are handled prior to MPI_Init. However, there have been times where that was not the case. > > Can you check what the Cray T3D does w.r.t. arguments passed to the host node appearing on the compute nodes? :-) No T3D’s in service. The more general question is whether vendors support a new version of MPI on old hardware for which there is no longer Fortran compiler support. If you can’t compile the code that calls the new MPI routine, them I’d assume the new routine is not relevant to users of the system. > > More seriously, does Fortran 2008 require that arguments passed to the invocation of mpirun (or equivalent) appear at every process in a multi-process MPI program? > Well, the Fortran standard says nothing about MPI, as should be the case. The method for launching a program is intentionally outside the scope of the standard. However, you make a reasonable point. The current standard has a sentence "The effects of calling COMMAND_ARGUMENT_COUNT, EXECUTE_COMMAND_LINE , GET_COMMAND, GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT_VARIABLE on any image other than image 1 are processor dependent.” . In discussions for the upcoming Fortran 2015 standard, people realized this was a silly restriction, and all the routines except EXECUTE_COMMAND_LINE were removed from this sentence. Vendors already were consistent that command line stuff worked on any image, so the “processor dependent” bit was unnecessary. Cheers, Bill > Jeff > > Jeff > > On Mon, Nov 9, 2015 at 8:56 AM, Bill Long <longb(a)cray.com> wrote: > > On Nov 9, 2015, at 8:56 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > > > > > On Mon, Nov 9, 2015 at 6:37 AM, Bill Long <longb(a)cray.com> wrote: > > > > On Nov 9, 2015, at 8:24 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > > > Did you read the ticket? We need this for the same reason MPI_Init() takes argc/argv even though C main() already has them. > > > > But the C standard does not implicitly assume every program is parallel. > > > > > > Correct. Nor can MPI assume that argc/argv will magically appear on the compute nodes when the job is launched from somewhere else. > > > > Agreed. My point is that Fortran is not the same as C. > > > > > > > While it may be true that process managers are magically fixing argc/argv, this is not guaranteed by any standard. > > > > The Fortran standard is intentionally vague to allow for environments where there is no command line, but rather (for example) the code starts executing by clicking a graphic button on the screen. The standard is likely to not include specific words about program launchers that might turn into bit rot in the future. If your favorite compiler returns the launcher text as part of the command line, complain. > > > > > > Complaining is fun, but has no teeth without a standard. Many vendors are quite strict about standards and reject feature requests that improve user experience if they lack justification in a standard. I can cite numerous vendors here… > > The overriding intent of a language standard is portability. You would have poor portability of a code if moving it from one machine to another resulted in different command argument information from get_command or get_command_argument. The intention is that the routine return the command line arguments that the program knows about, not some cryptic stuff from aprun, srun, or mpirun. I did try all the compilers I have access to on a trivial code: > > > cat test.f90 > program test > character(1000) command > integer length > call get_command (command, length) > print *, command(1:length) > end program test > > > ftn test.f90 > > aprun -n1 ./a.out -x > ./a.out -x > Application 15961022 resources: utime ~0s, stime ~0s, Rss ~4176, inblocks ~4479, outblocks ~11453 > > module swap PrgEnv-cray PrgEnv-intel > > ftn test.f90 > > aprun -n1 ./a.out -x > ./a.out -x > Application 15961023 resources: utime ~0s, stime ~0s, Rss ~4176, inblocks ~2967, outblocks ~7756 > > module swap PrgEnv-intel PrgEnv-pgi > > ftn test.f90 > > aprun -n1 ./a.out -x > ./a.out -x > Application 15961025 resources: utime ~0s, stime ~0s, Rss ~4172, inblocks ~3038, outblocks ~8308 > l> module swap PrgEnv-pgi PrgEnv-gnu > > ftn test.f90 > > aprun -n1 ./a.out -x > ./a.out -x > Application 15961026 resources: utime ~0s, stime ~0s, Rss ~4172, inblocks ~3031, outblocks ~8027 > > All of them produced the expected output (excluding the “aprun -n1” launcher text). > > Perhaps we could add a Note in the Fortran standard explaining this, but it looks like vendors have already figured it out. > > Cheers, > Bill > > > > > > > While the new proposed routines are trivial to implement (assuming they have the same arguments as the corresponding Fortran ones), they add to one of MPI’s most serious flaws - way to many routines already. > > > > > > As you say, they are trivial to implement. The size of the standard is an irrelevant argument. Users don't read what they don't need to read and users shouldn't be reading the spec most of the time anyways. > > > > Jeff > > > > Cheers, > > Bill > > > > > > > > > > Jeff > > > > > > On Mon, Nov 9, 2015 at 6:21 AM, Bill Long <longb(a)cray.com> wrote: > > > Hi Jeff, > > > > > > I don’t see the value of this. The Fortran intrinsics GET_COMMAND and friends should already do what you want. Fortran programs are now presumed parallel. The intrinsics should know how to strip off the “launcher” part of the command line. At least that is how the Cray versions have worked from the beginning. Experiments are in order for other vendors, as a check. > > > > > > Cheers, > > > Bill > > > > > > > > > > > > On Nov 9, 2015, at 8:13 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > > > > > we did a lot of work on https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/351. do we intend to move forward this for MPI 4+? if yes, we need to migrate the trac ticket to a github issue. > > > > > > > > jeff > > > > > > > > -- > > > > Jeff Hammond > > > > jeff.science(a)gmail.com > > > > http://jeffhammond.github.io/ > > > > _______________________________________________ > > > > mpiwg-fortran mailing list > > > > mpiwg-fortran(a)lists.mpi-forum.org > > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > Bill Long longb(a)cray.com > > > Fortran Technical Support & voice: 651-605-9024 > > > Bioinformatics Software Development fax: 651-605-9142 > > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > > > > > > > _______________________________________________ > > > mpiwg-fortran mailing list > > > mpiwg-fortran(a)lists.mpi-forum.org > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > > > > > -- > > > Jeff Hammond > > > jeff.science(a)gmail.com > > > http://jeffhammond.github.io/ > > > _______________________________________________ > > > mpiwg-fortran mailing list > > > mpiwg-fortran(a)lists.mpi-forum.org > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > Bill Long longb(a)cray.com > > Fortran Technical Support & voice: 651-605-9024 > > Bioinformatics Software Development fax: 651-605-9142 > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > > > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > -- > > Jeff Hammond > > jeff.science(a)gmail.com > > http://jeffhammond.github.io/ > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > Bill Long longb(a)cray.com > Fortran Technical Support & voice: 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] ticket 351
by Jeff Hammond 09 Nov '15

09 Nov '15

MPI implementations today are remarkably standardized w.r.t. process launching such that standard arguments are handled prior to MPI_Init. However, there have been times where that was not the case. Can you check what the Cray T3D does w.r.t. arguments passed to the host node appearing on the compute nodes? :-) More seriously, does Fortran 2008 require that arguments passed to the invocation of mpirun (or equivalent) appear at every process in a multi-process MPI program? Jeff Jeff On Mon, Nov 9, 2015 at 8:56 AM, Bill Long <longb(a)cray.com> wrote: > > On Nov 9, 2015, at 8:56 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > > > > > On Mon, Nov 9, 2015 at 6:37 AM, Bill Long <longb(a)cray.com> wrote: > > > > On Nov 9, 2015, at 8:24 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > > > Did you read the ticket? We need this for the same reason MPI_Init() > takes argc/argv even though C main() already has them. > > > > But the C standard does not implicitly assume every program is parallel. > > > > > > Correct. Nor can MPI assume that argc/argv will magically appear on the > compute nodes when the job is launched from somewhere else. > > > > Agreed. My point is that Fortran is not the same as C. > > > > > > > While it may be true that process managers are magically fixing > argc/argv, this is not guaranteed by any standard. > > > > The Fortran standard is intentionally vague to allow for environments > where there is no command line, but rather (for example) the code starts > executing by clicking a graphic button on the screen. The standard is > likely to not include specific words about program launchers that might > turn into bit rot in the future. If your favorite compiler returns the > launcher text as part of the command line, complain. > > > > > > Complaining is fun, but has no teeth without a standard. Many vendors > are quite strict about standards and reject feature requests that improve > user experience if they lack justification in a standard. I can cite > numerous vendors here… > > The overriding intent of a language standard is portability. You would > have poor portability of a code if moving it from one machine to another > resulted in different command argument information from get_command or > get_command_argument. The intention is that the routine return the command > line arguments that the program knows about, not some cryptic stuff from > aprun, srun, or mpirun. I did try all the compilers I have access to on a > trivial code: > > > cat test.f90 > program test > character(1000) command > integer length > call get_command (command, length) > print *, command(1:length) > end program test > > > ftn test.f90 > > aprun -n1 ./a.out -x > ./a.out -x > Application 15961022 resources: utime ~0s, stime ~0s, Rss ~4176, inblocks > ~4479, outblocks ~11453 > > module swap PrgEnv-cray PrgEnv-intel > > ftn test.f90 > > aprun -n1 ./a.out -x > ./a.out -x > Application 15961023 resources: utime ~0s, stime ~0s, Rss ~4176, inblocks > ~2967, outblocks ~7756 > > module swap PrgEnv-intel PrgEnv-pgi > > ftn test.f90 > > aprun -n1 ./a.out -x > ./a.out -x > Application 15961025 resources: utime ~0s, stime ~0s, Rss ~4172, inblocks > ~3038, outblocks ~8308 > l> module swap PrgEnv-pgi PrgEnv-gnu > > ftn test.f90 > > aprun -n1 ./a.out -x > ./a.out -x > Application 15961026 resources: utime ~0s, stime ~0s, Rss ~4172, inblocks > ~3031, outblocks ~8027 > > All of them produced the expected output (excluding the “aprun -n1” > launcher text). > > Perhaps we could add a Note in the Fortran standard explaining this, but > it looks like vendors have already figured it out. > > Cheers, > Bill > > > > > > > While the new proposed routines are trivial to implement (assuming they > have the same arguments as the corresponding Fortran ones), they add to > one of MPI’s most serious flaws - way to many routines already. > > > > > > As you say, they are trivial to implement. The size of the standard is > an irrelevant argument. Users don't read what they don't need to read and > users shouldn't be reading the spec most of the time anyways. > > > > Jeff > > > > Cheers, > > Bill > > > > > > > > > > Jeff > > > > > > On Mon, Nov 9, 2015 at 6:21 AM, Bill Long <longb(a)cray.com> wrote: > > > Hi Jeff, > > > > > > I don’t see the value of this. The Fortran intrinsics GET_COMMAND and > friends should already do what you want. Fortran programs are now presumed > parallel. The intrinsics should know how to strip off the “launcher” part > of the command line. At least that is how the Cray versions have worked > from the beginning. Experiments are in order for other vendors, as a > check. > > > > > > Cheers, > > > Bill > > > > > > > > > > > > On Nov 9, 2015, at 8:13 AM, Jeff Hammond <jeff.science(a)gmail.com> > wrote: > > > > > > > we did a lot of work on > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/351. do we intend to > move forward this for MPI 4+? if yes, we need to migrate the trac ticket > to a github issue. > > > > > > > > jeff > > > > > > > > -- > > > > Jeff Hammond > > > > jeff.science(a)gmail.com > > > > http://jeffhammond.github.io/ > > > > _______________________________________________ > > > > mpiwg-fortran mailing list > > > > mpiwg-fortran(a)lists.mpi-forum.org > > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > Bill Long > longb(a)cray.com > > > Fortran Technical Support & voice: > 651-605-9024 > > > Bioinformatics Software Development fax: > 651-605-9142 > > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > > > > > > > _______________________________________________ > > > mpiwg-fortran mailing list > > > mpiwg-fortran(a)lists.mpi-forum.org > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > > > > > -- > > > Jeff Hammond > > > jeff.science(a)gmail.com > > > http://jeffhammond.github.io/ > > > _______________________________________________ > > > mpiwg-fortran mailing list > > > mpiwg-fortran(a)lists.mpi-forum.org > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > Bill Long > longb(a)cray.com > > Fortran Technical Support & voice: > 651-605-9024 > > Bioinformatics Software Development fax: > 651-605-9142 > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > > > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > -- > > Jeff Hammond > > jeff.science(a)gmail.com > > http://jeffhammond.github.io/ > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > Bill Long > longb(a)cray.com > Fortran Technical Support & voice: > 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] ticket 351
by Bill Long 09 Nov '15

09 Nov '15

On Nov 9, 2015, at 8:56 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > On Mon, Nov 9, 2015 at 6:37 AM, Bill Long <longb(a)cray.com> wrote: > > On Nov 9, 2015, at 8:24 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > Did you read the ticket? We need this for the same reason MPI_Init() takes argc/argv even though C main() already has them. > > But the C standard does not implicitly assume every program is parallel. > > > Correct. Nor can MPI assume that argc/argv will magically appear on the compute nodes when the job is launched from somewhere else. > Agreed. My point is that Fortran is not the same as C. > > > > While it may be true that process managers are magically fixing argc/argv, this is not guaranteed by any standard. > > The Fortran standard is intentionally vague to allow for environments where there is no command line, but rather (for example) the code starts executing by clicking a graphic button on the screen. The standard is likely to not include specific words about program launchers that might turn into bit rot in the future. If your favorite compiler returns the launcher text as part of the command line, complain. > > > Complaining is fun, but has no teeth without a standard. Many vendors are quite strict about standards and reject feature requests that improve user experience if they lack justification in a standard. I can cite numerous vendors here… The overriding intent of a language standard is portability. You would have poor portability of a code if moving it from one machine to another resulted in different command argument information from get_command or get_command_argument. The intention is that the routine return the command line arguments that the program knows about, not some cryptic stuff from aprun, srun, or mpirun. I did try all the compilers I have access to on a trivial code: > cat test.f90 program test character(1000) command integer length call get_command (command, length) print *, command(1:length) end program test > ftn test.f90 > aprun -n1 ./a.out -x ./a.out -x Application 15961022 resources: utime ~0s, stime ~0s, Rss ~4176, inblocks ~4479, outblocks ~11453 > module swap PrgEnv-cray PrgEnv-intel > ftn test.f90 > aprun -n1 ./a.out -x ./a.out -x Application 15961023 resources: utime ~0s, stime ~0s, Rss ~4176, inblocks ~2967, outblocks ~7756 > module swap PrgEnv-intel PrgEnv-pgi > ftn test.f90 > aprun -n1 ./a.out -x ./a.out -x Application 15961025 resources: utime ~0s, stime ~0s, Rss ~4172, inblocks ~3038, outblocks ~8308 l> module swap PrgEnv-pgi PrgEnv-gnu > ftn test.f90 > aprun -n1 ./a.out -x ./a.out -x Application 15961026 resources: utime ~0s, stime ~0s, Rss ~4172, inblocks ~3031, outblocks ~8027 All of them produced the expected output (excluding the “aprun -n1” launcher text). Perhaps we could add a Note in the Fortran standard explaining this, but it looks like vendors have already figured it out. Cheers, Bill > > While the new proposed routines are trivial to implement (assuming they have the same arguments as the corresponding Fortran ones), they add to one of MPI’s most serious flaws - way to many routines already. > > > As you say, they are trivial to implement. The size of the standard is an irrelevant argument. Users don't read what they don't need to read and users shouldn't be reading the spec most of the time anyways. > > Jeff > > Cheers, > Bill > > > > > > Jeff > > > > On Mon, Nov 9, 2015 at 6:21 AM, Bill Long <longb(a)cray.com> wrote: > > Hi Jeff, > > > > I don’t see the value of this. The Fortran intrinsics GET_COMMAND and friends should already do what you want. Fortran programs are now presumed parallel. The intrinsics should know how to strip off the “launcher” part of the command line. At least that is how the Cray versions have worked from the beginning. Experiments are in order for other vendors, as a check. > > > > Cheers, > > Bill > > > > > > > > On Nov 9, 2015, at 8:13 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > > > we did a lot of work on https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/351. do we intend to move forward this for MPI 4+? if yes, we need to migrate the trac ticket to a github issue. > > > > > > jeff > > > > > > -- > > > Jeff Hammond > > > jeff.science(a)gmail.com > > > http://jeffhammond.github.io/ > > > _______________________________________________ > > > mpiwg-fortran mailing list > > > mpiwg-fortran(a)lists.mpi-forum.org > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > Bill Long longb(a)cray.com > > Fortran Technical Support & voice: 651-605-9024 > > Bioinformatics Software Development fax: 651-605-9142 > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > > > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > -- > > Jeff Hammond > > jeff.science(a)gmail.com > > http://jeffhammond.github.io/ > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > Bill Long longb(a)cray.com > Fortran Technical Support & voice: 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] ticket 351
by Jeff Hammond 09 Nov '15

09 Nov '15

On Mon, Nov 9, 2015 at 6:37 AM, Bill Long <longb(a)cray.com> wrote: > > On Nov 9, 2015, at 8:24 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > Did you read the ticket? We need this for the same reason MPI_Init() > takes argc/argv even though C main() already has them. > > But the C standard does not implicitly assume every program is parallel. > > Correct. Nor can MPI assume that argc/argv will magically appear on the compute nodes when the job is launched from somewhere else. > > > > While it may be true that process managers are magically fixing > argc/argv, this is not guaranteed by any standard. > > The Fortran standard is intentionally vague to allow for environments > where there is no command line, but rather (for example) the code starts > executing by clicking a graphic button on the screen. The standard is > likely to not include specific words about program launchers that might > turn into bit rot in the future. If your favorite compiler returns the > launcher text as part of the command line, complain. > > Complaining is fun, but has no teeth without a standard. Many vendors are quite strict about standards and reject feature requests that improve user experience if they lack justification in a standard. I can cite numerous vendors here... > While the new proposed routines are trivial to implement (assuming they > have the same arguments as the corresponding Fortran ones), they add to > one of MPI’s most serious flaws - way to many routines already. > > As you say, they are trivial to implement. The size of the standard is an irrelevant argument. Users don't read what they don't need to read and users shouldn't be reading the spec most of the time anyways. Jeff > Cheers, > Bill > > > > > > Jeff > > > > On Mon, Nov 9, 2015 at 6:21 AM, Bill Long <longb(a)cray.com> wrote: > > Hi Jeff, > > > > I don’t see the value of this. The Fortran intrinsics GET_COMMAND and > friends should already do what you want. Fortran programs are now presumed > parallel. The intrinsics should know how to strip off the “launcher” part > of the command line. At least that is how the Cray versions have worked > from the beginning. Experiments are in order for other vendors, as a > check. > > > > Cheers, > > Bill > > > > > > > > On Nov 9, 2015, at 8:13 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > > > we did a lot of work on > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/351. do we intend to > move forward this for MPI 4+? if yes, we need to migrate the trac ticket > to a github issue. > > > > > > jeff > > > > > > -- > > > Jeff Hammond > > > jeff.science(a)gmail.com > > > http://jeffhammond.github.io/ > > > _______________________________________________ > > > mpiwg-fortran mailing list > > > mpiwg-fortran(a)lists.mpi-forum.org > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > Bill Long > longb(a)cray.com > > Fortran Technical Support & voice: > 651-605-9024 > > Bioinformatics Software Development fax: > 651-605-9142 > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > > > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > -- > > Jeff Hammond > > jeff.science(a)gmail.com > > http://jeffhammond.github.io/ > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > Bill Long > longb(a)cray.com > Fortran Technical Support & voice: > 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] ticket 351
by Bill Long 09 Nov '15

09 Nov '15

On Nov 9, 2015, at 8:24 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > Did you read the ticket? We need this for the same reason MPI_Init() takes argc/argv even though C main() already has them. But the C standard does not implicitly assume every program is parallel. > > While it may be true that process managers are magically fixing argc/argv, this is not guaranteed by any standard. The Fortran standard is intentionally vague to allow for environments where there is no command line, but rather (for example) the code starts executing by clicking a graphic button on the screen. The standard is likely to not include specific words about program launchers that might turn into bit rot in the future. If your favorite compiler returns the launcher text as part of the command line, complain. While the new proposed routines are trivial to implement (assuming they have the same arguments as the corresponding Fortran ones), they add to one of MPI’s most serious flaws - way to many routines already. Cheers, Bill > > Jeff > > On Mon, Nov 9, 2015 at 6:21 AM, Bill Long <longb(a)cray.com> wrote: > Hi Jeff, > > I don’t see the value of this. The Fortran intrinsics GET_COMMAND and friends should already do what you want. Fortran programs are now presumed parallel. The intrinsics should know how to strip off the “launcher” part of the command line. At least that is how the Cray versions have worked from the beginning. Experiments are in order for other vendors, as a check. > > Cheers, > Bill > > > > On Nov 9, 2015, at 8:13 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > > we did a lot of work on https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/351. do we intend to move forward this for MPI 4+? if yes, we need to migrate the trac ticket to a github issue. > > > > jeff > > > > -- > > Jeff Hammond > > jeff.science(a)gmail.com > > http://jeffhammond.github.io/ > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > Bill Long longb(a)cray.com > Fortran Technical Support & voice: 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0