1) Why not support all three modes?
1 is implemented by using current blocking collective, followed by
local completion in the worst case.
2 is implemented by local allocation of resources needed, with the
second phase doing the blocking collective, and cleaning up, in the
worst case.
3 provides the cleanest implementation, but the least promise to the
user not to be hampered immediately by non-local concerns.
Our proposal is specifically, that all three modes be offered, wlog, and
with clear explanations to users about cases and expected behaviors. Why
must this be exclusive, unless we anticipate that all applications will
want the same thing?
It will be quality of implementation question as to which of these
modes actually offers best overlap. The semantic guarantee of modes
1 and 2 will be useful independent of whether there is overlap.
In other words, we wish to separate concerns between guarantee of
non-blocking, and possibility of overlapping. This is in the same
vein as the much lamanted tags and multi-communication-allocation
proposals, but we think more pallatable than either of these.
-Tony
PS Some things for MPI minus 2...
Here is one potential set of responses from a pair of regular
commentators:
* too much work to implement more than one mode (so pick one)
* we will make the modes we don't like very slow on purpose (or worse)
* we have special hardware that won't allow us to have more than one mode,
or will have it someday, or we will ask it to be developed ASAP, so we
can rely on this reasoning now.
Another implementor might say:
* "his machines" need more shared memory mapping to support modes, so less
is more
One prolific theoretician might say:
* more modes have yet to be considered, and here they are (too long to
offer here, or face complaints from a certain lurker)
A well known participant might say:
* GR solves this, if the following changes are offered (too long to
provide here for same reason as above)
Another well-thought-of theoretician might say:
* this is not a good idea for the forum to consider
On Thu, 6 Feb 1997, Rolf Rabenseifner wrote:
> Date: Thu, 6 Feb 1997 16:22:46 +0100 (MEZ)
> From: Rolf Rabenseifner <Rabenseifner@RUS.Uni-Stuttgart.DE>
> To: James Cownie <jcownie@dolphinics.com>
> Cc: mpi-coll@mcs.anl.gov
> Subject: Re: 2-phase collective
>
> > Since at least one of the calls must be collective the options are
> >
> > Start End
> >
> > 1) collective local
> > 2) local collective
> > 3) collective collective
> >
> > Option 1 gives you nothing beyond what you already have, so can be
> > ignored.
> > Option 2 is what Lloyd appears to be proposing.
> and what the 4th Feb draft says
> > Option 3 is what the text currently (15th Jan. draft) says.
>
> After the discussion for me it looks that the best solution is 3.
> It simplifies implementation and does not complicates application
> programming excessively.
>
> I want to ask whether this is a consent?
>
> (Then we could change the Feb. 4th draft to this option.)
>
> Rolf
>
>
>
> Rolf Rabenseifner (Computer Center )
> Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
> Allmandring 30 Phone: ++49 711 6855530
> D-70550 Stuttgart 80 FAX: ++49 711 6787626
> Germany rabenseifner@rus.uni-stuttgart.de
>
Anthony Skjellum, PhD, Associate Professor of Computer Science;
Mississippi State University, Department of Computer Science & NSF ERC
Butler, Rm 300, PO Box 9637, Corner of Perry&Barr, Mississippi State,MS 39762
(601)325-8435 FAX: (601)325-8997; http://www.erc.msstate.edu/~tony;
"Persistence is fertile." ; e-mail: tony@cs.msstate.edu; Try MPI!