Subject: Rik's comments on Lyndon's Proposal I

From: [email-masked]
Date: Mon, 22 Mar 93 01:47:05 PST

>>>>> I have added here a few additions to Tony's comments.
>>>>> I have also deleted the bulk of the proposal regarding which
>>>>> I have no comments at 1:45 AM.
>>>>> -- Rik
%****
%**** Below are my comments on Lyndon's Proposal I.  In the next paragraph
%**** I note that we are actually converging to less than N proposals, though
%**** I have not seen Lyndon's new II proposal yet.  Does  it exist now?
%****
%**** To achieve a reasonable presentation at Dallas, we can have multiple
%**** proposals still on table (I think this a fair, well-thought-out
%**** approach, but if we can condense some, let's do it).
%**** 
%****
%**** After reading V, making my comments, and making my comments
%**** in addition to Lyndon's comments, I am convinced we can
%**** advance proposal V into something that is acceptable in the
%**** III/IV mold, without a further III/IV proposal.  Rik's
%**** dropping of the static context concept has simplified our
%**** group's efforts considerably, and I cannot disambiguate my
%**** III/IV proposal from Proposal V, given the Lyndon and Tony
%**** provisos and suggested improvements.  This is not a wimp out
%**** on my part.  I do not see benefit of advancing something that
%**** will look 90% like Proposal V at this point, and 97% like it
%**** if the Lyndon/Tony comments obtain in it (which they would if
%**** I wrote it now).  
%**** I would prefer that we hone Proposal V.  If Rik wants to keep
%**** his style, then I propose that Proposal III/IV become exactly
%**** what I just said, a reworking of V + comments.
%**** However, I think this will cause an unnecessary delay and
%**** digression just to achieve details.  Instead, we might pull
%**** such choices into Proposal V at this time (server vs. no server).
%**** to make what is common in our "approaches" more obvious.
%**** - Tony
%****
%**** (PS, Lyndon: Rik/Tony/Lyndon are authors of whole paper, because
%****  we are all working on this, and because one of us (ie, me) will
%****  make the final document cohesive, create a unified style, format,
%****  set of meanings.  This is the nature of collaboration.  I do
%****  not propose to include our other co-conspirators on such a document's
%****  list of authors, as there has been minimal input from them.  I
%****  Think that Rusty/Bill and Rik/Tony/Lyndon are operating equivalently.)
>>>>>
>>>>> I happens to think that the style of my draft proposal V stinks.
>>>>> I had much too much trouble becoming (fairly) sure that the content
>>>>> was right, to also make it readable.
>>>>> --Rik

....

A group may be created by identical duplication of an existing group. 
For example, {\tt gidb = mpi\_grp\_duplication(gida)} where {\tt gidb}
is the group identifier of the newly created group and {\tt gida} is the
identifier of an existing group. The created group inherits all properties
of the source group, including any topological properties. This operation
has the same synchronisation properties as creation of group by
definition.
%**** It is not obvious to me that we want to enforce topology at this
%**** juncture.  However, we could register topology information in
%**** the extensible structure strategy of Proposal V.
%****
>>>>> Why such strong synchronization?!
>>>>> If this has the same synchronization properties as creation,
>>>>> then it won't return until all members have made the call.
>>>>> But that means you actually have to sync everybody, which
>>>>> implies 2 log(P) messages.  Isn't it enough to just require
>>>>> a loosely synchronous call, and use a counting strategy>

----------------------------------------------------------------------
[email-masked] (alias 'd39135')   Rik Littlefield
Tel: 509-375-3927                         Pacific Northwest Lab, MS K1-87
Fax: 509-375-6631                         P.O.Box 999, Richland, WA  99352

---

From: L J Clarke <[email-masked]>
Date: Mon, 22 Mar 93 10:01:09 GMT

Hi Rik

Thanks for the comments.

The proposal which I had sent out is dead.  It has been replaced with a
cut-and-paste of the section on contexts which Marc wrote into the
point-to-point document. 

There is no proposal II.  There is however a proposal VI.  This
naming/numbering is Tony's suggestion with which I concur.

I will propogate the relevant comments you have made into the LaTeX of
proposal VI (as identified LaTeX comments) and repost. I really am very
sorry to have messed you about.

I have a lot of other email, incl.  from yourself, to read.  (I am
cancelling meetings left, right and centre here.) I will post later
today. 

Best Wishes
Lyndon

         /--------------------------------------------------------\
    e||) | Lyndon J Clarke    Edinburgh Parallel Computing Centre | e||) 
    c||c | Tel: 031 650 5021  Email: [email-masked]  | c||c 
         \--------------------------------------------------------/

---

From: [email-masked]
Date: Mon, 22 Mar 93 08:32:32 PST

Lyndon says
> naming/numbering is Tony's suggestion with which I concur.

Is this the same or different from the "proposal VI" I sketched
last night?  For reference, that was

(Rik said)
> Here's a sketch of a new proposal (VI ?).
> 
> . The functionality of point-to-point communications is per Snir,
>   Lusk, and Gropp, augmented by my proposed MPI_FORM_CONTEXT to allow
>   assembling arbitrary collections of processes.  (Marc has already
>   accepted this in a private email to me -- don't know why he
>   didn't post it.)
> 
> . Performance expectations of point-to-point communications are
>   explicitly stated as follows: 
> 
>   - MPI_COPY_CONTEXT does not synchronize the participating processes
>     and costs significantly less than a point-to-point fanout among
>     them (e.g., it uses a communication-free counting strategy);
> 
>   - all other context formation routines cost no more than if they
>     were implemented using a single fanin/fanout among the
>     participating processes;
> 
>   - translation of (context,rank) to absolute processor ID costs no
>     more than if it were implemented via the lookup table that Snir
>     suggests.
> 
> . Groups and contexts are not equal.  A group consists of a base
>   context (from which other contexts can be created quickly by
>   MPI_COPY_CONTEXT), plus topology information, plus my cacheing
>   facility.

Lyndon says
> I really am very sorry to have messed you about.

I have no idea what this refers to.  It would bother me to
have MPI produce a bad standard.  Not much else does.  I would
be delighted to have all of my specific suggestions and/or words
replaced by something better.

--Rik