[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [mpi-21] ABI: feature categories



If you do decide to standardize the way in which MPI codes are started,
then you surely must make that an extension to the base standard, so
that MPI implementations in environments where starting a program makes
no sense (for instance some embedded processor of some sort) can still
have standard conforming MPI implementations.

Remember that so far MPI has never mandated properties of the
environment in which it is used. (So it makes only suggestions about how
MPI programs are started, doesn't require specific compiler properties,
or that the system support the one true editor :-))

-- Jim

James Cownie <james.h.cownie@xxxxxxxxx>
SSG/DPD/PAT
Tel: +44 117 9071438




> -----Original Message-----
> From: owner-mpi-21@xxxxxxxxxxxxx [mailto:owner-mpi-21@xxxxxxxxxxxxx]
On
> Behalf Of William Yu
> Sent: 13 January 2008 23:13
> To: mpi-21@xxxxxxxxxxxxx
> Subject: Re: [mpi-21] ABI: feature categories
> 
> I think we just have to standardize the behavior of things like mpirun
and
> mpiexec such as what cwd does it use by default, order of loading
> arguments in the system and others. Other items like process loading
order
> could probably also matter.
> 
> However, i have not been exposed to many mpi implementations that have
> non-uniform implementations of mpirun and mpiexec to comment enough on
> this.
> 
> 
> ________________ Reply Header ________________
> Subject:	Re: [mpi-21] ABI: feature categories
> Author:	Greg Bronevetsky <bronevetsky1@xxxxxxxx>
> Date:		January 13th 2008 10:21 pm
> 
> To me its clear that standardizing mpistart,
> stdout/stderr/stdin and environment variables
> will provide large usability gains without much
> of a cost to MPI implementors (correct me if I'm
> wrong). Interactions between MPI and the batch
> scheduler seem to be difficult to standardize.
> How are people handling this now? Can somebody
> explain the issues with stack sizes, MPI I/O and
> CWD? I'm not familiar with these.
> 
> Greg Bronevetsky
> Post-Doctoral Researcher
> 1028 Building 451
> Lawrence Livermore National Lab
> (925) 424-5756
> bronevetsky1@xxxxxxxx
> 
> At 02:10 PM 1/13/2008, Greg Bronevetsky wrote:
> >To clarify the debate surrounding the ABI
> >proposal I've gone through Greg Lindahl's talk
> >and broken the main points of the talk down into the following
> categories:
> >         User-MPI interactions
> >         Application-MPI interactions
> >         System-MPI interactions
> >As we've discussed, about morph layers address
> >all the points under the "Application-MPI
> >interactions" category. In other words, if we
> >used morph layers we wouldn't need to
> >standardize things like mpi.h. What's left are
> >the User-MPI and System-MPI interactions. The
> >question that I would like to put forward is:
> >How useful are these? Most of the discussion
> >I've heard recently focuses on Application-MPI
> >interactions. If we can table this for the time
> >being until morph layers can be evaluated, is
> >there enough support to proceed with the rest of
> >the proposal or is the Application-MPI
> >interactions the core part? Please speak up.
> >
> >User-MPI interactions
> >         ?mpistart? -- ?mpirun? with standard args
> >                 Start over: ?mpistart? with standardized args
> >                 Require features such as
> > supporting pipes of stdin, stdout, error
> >                 --batch and -batch-wait to
> > assist scripting in the presense of batch queues... noop if no queue
sys
> >Application-MPI interactions
> >         Fully specify what's in <mpi.h> and ?mpif.h?
> >                 Variably-sized items have to be nailed down
> >                 MPI_Status must have fixed length
> >         Need a sane shared-library setup to avoid relinking
> >                 I think this means we need 1
> > base library instead of the usual chaos
> >                 Implementers can dlopen() additional libs as needed
> >                 Perhaps we can have a clever
> > upward-compatible scheme for MPI 1 and MPI 2 libs
> >System-MPI interactions
> >         Fully specify startup and queue system interaction in a
flexible
> way
> >                 Queue sys handles creation of MPI processes
> >                 Standard command-line for MPI
> > process, with enough info to connect to the ? job?
> >                 MPI implementation provides ? job? process; all
> >                 MPI processes contact to coordinate.
> >                         ? job? process started by mpistart
> >                 Queue sys ensures all MPI processes exit at end.
> >                 I think this supports all
> > existing queue systems and MPI implementations
> >         Specify environmental items so that most apps are portable
> >                 Getenv / putenv: most
> > implementations don't propagate env vars to
> > ranks 1+; few support using putenv to other processes.
> >                 Cwd depends on batch system and sysadmin
> >                         2 choices: least common denominator, or
query
> fns?
> >                 Stack size. Usually painful for users to fix.
> >                 stdin/stdout/stderr... oh, don't forget buffering...
> >                 MPI-I/O.
> >                 Actions before/after mpi_init/finalize
> >
> >Greg Bronevetsky
> >Post-Doctoral Researcher
> >1028 Building 451
> >Lawrence Livermore National Lab
> >(925) 424-5756
> >bronevetsky1@xxxxxxxx
> 

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.