[MPIWG Fortran] ticket 351
Jeff Hammond
jeff.science at gmail.com
Mon Nov 9 15:03:48 CST 2015
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 at cray.com> wrote:
>
> On Nov 9, 2015, at 11:43 AM, Jeff Hammond <jeff.science at 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 at cray.com> wrote:
> >
> > On Nov 9, 2015, at 8:56 AM, Jeff Hammond <jeff.science at gmail.com> wrote:
> >
> > >
> > >
> > > On Mon, Nov 9, 2015 at 6:37 AM, Bill Long <longb at cray.com> wrote:
> > >
> > > On Nov 9, 2015, at 8:24 AM, Jeff Hammond <jeff.science at 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 at 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 at 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 at gmail.com
> > > > > http://jeffhammond.github.io/
> > > > > _______________________________________________
> > > > > mpiwg-fortran mailing list
> > > > > mpiwg-fortran at lists.mpi-forum.org
> > > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> > > >
> > > > Bill Long
> longb at 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 at lists.mpi-forum.org
> > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> > > >
> > > >
> > > >
> > > > --
> > > > Jeff Hammond
> > > > jeff.science at gmail.com
> > > > http://jeffhammond.github.io/
> > > > _______________________________________________
> > > > mpiwg-fortran mailing list
> > > > mpiwg-fortran at lists.mpi-forum.org
> > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> > >
> > > Bill Long
> longb at 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 at lists.mpi-forum.org
> > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> > >
> > >
> > >
> > > --
> > > Jeff Hammond
> > > jeff.science at gmail.com
> > > http://jeffhammond.github.io/
> > > _______________________________________________
> > > mpiwg-fortran mailing list
> > > mpiwg-fortran at lists.mpi-forum.org
> > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >
> > Bill Long
> longb at 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 at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
> >
> >
> >
> > --
> > Jeff Hammond
> > jeff.science at gmail.com
> > http://jeffhammond.github.io/
> > _______________________________________________
> > mpiwg-fortran mailing list
> > mpiwg-fortran at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
> Bill Long
> longb at 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 at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>
--
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20151109/960ffd3d/attachment-0001.html>
More information about the mpiwg-fortran
mailing list