Subject: latest lyndon-mail

From: Tony Skjellum <[email-masked]>
Date: Wed, 10 Mar 93 05:28:59 CST

**** My latest comments start lines with ****.
**** - Tony

>From [email-masked] Wed Mar 10 05:12:18 1993
>Received: from epcc.ed.ac.uk (daedalus.epcc.ed.ac.uk) by Aurora.CS.MsState.Edu (4.1/6.0s-FWP);
>	   id AA09849; Wed, 10 Mar 93 05:11:49 CST
>Date: Wed, 10 Mar 93 11:14:44 GMT
>Message-Id: <[email-masked]>
>From: L J Clarke <[email-masked]>
>Subject: [Tony Skjellum: Re: [Tony Skjellum: Re: Intra/inter group communications, UBONBOUND, PIDs]To: Tony Skjellum <[email-masked]>, Jim Cownie <[email-masked]>, 
>    Rik Littlefield <[email-masked]>, 
>    Sanjay Ranka <[email-masked]>
>Reply-To: [email-masked]
>Apparently-To: [email-masked]
>Apparently-To: [email-masked]
>Apparently-To: [email-masked]
>Apparently-To: [email-masked]
>Status: R
>
>Good morning
>
>Lyndon replying to Tony replying to Lyndon replying to Tony replying to ...
>
>
>> >(again). Please help.
>> >
>> >First way, "context" is being used to indicate is a binding of group
>> >plus more, and therefore I understand it easily. 
>> >
>> >Second way, "context" is being used in a way which I understand.
>> >
>> ***** I think my comment made more sense to me when I wrote it before.
>> ***** I withdraw it.
>
>Arrrghhhh! I realise that I have badly typed the "Second way", which
>should say that "context" is being used in a whay which I do not
>understand. This is very badly typed indeed, apologies.
>
>I think this was a request for information/sharing of understanding,
>which I expect I still need.
**** I was viewing the whole context-thing as a "port" specification.
**** How about a domain-wide name for a piece of mail to be delivered?
**** Such as mail from UK to US?  
**** I am still not sure this was cogent...
****

>> >The point is that you do not actually want to produce a new group.  You
>> >want to keep thinking of the two groups as seperate entities, each
>> >acting individually in a coherent fashion, and communicating with one
>> >another perhaps according to some rules based on ranks in each
>> >indicidual group. 
>> ***** I understand that, but why do you want to keep thinking of it that way,
>> ***** except for some possible performance benefit?
>> ****
>
>I tell you why, it's because we find it easy to think of it and discuss
>it in that way. This really is the whole point, expressive power.
****
**** I believe in the expressive-power argument, no problem.  I am
**** also willing to believe that we should keep the minimum cost of
**** inter-group down to the point where it remains useful.  It is
**** dynamicism of groups that motivates inter-group communication.
**** Else, the one-shot cost of merging groups, and staying intra-group
**** would not be unacceptable.  There must be some ineffable quality
**** of groups (dynamic need to change, for instance) that you hope for!
**** I agree with this abstractly, but please help me more...
****
>> >
>> >Same "I can read this two ways" as above. 
>> ***** OK, I withdraw this remark too.
>
>Look, I found it vague. I'd rather you helped me to understand, please.
>
**** Related thoughts...
**** I am trying to understand my original comment, myself.  I think
**** of context/group/rank_id as a MPI_TID, if you wish.  It all made more
**** sense to me structured that way, rather than having a pair of
**** contexts as a mechanism for inter-group.  In short, I felt we were
**** inventing our own TID called context/group/rank_id, and that this
**** was a nice structure, and superceded the PVM notion of a TID.
**** If I am foggy, sorry, but if we worked in those terms, with accessors
**** on such a TID, we would know how to handle some of the problems
**** described elsewhere.  For instance, we could have the meaning of
**** rank_id be group-scope/dependent.  Rank would be a nice, fast hash on 
**** static groups, and a slower, more complex thing to map for 
**** intergroup [are people still liking NUL/UNBOUND???].
****
>> >
>> >If this is an invitation to add a further proposal to the set we are
>> >doing, then I accept such invitation.  In fact, I can frame it as an
>> >extension of proposal I. 
>> ***** YES.
>
>Will do.
>
>> >
>> >> Of course, point-to-point could provide another set of procedures which
>> >> handle inter-group communication cleanly.  This is my preferred
>> >> approach, but again I don't suppose that this will be acceptable,
>> >> because so may people are already so concerned about the number of
>> >> procedures in the point-to-point section. 
>> >> ****
>> >> **** Again, why not try.  We need to fill in our matrix of proposals X
>> >> **** closures :-)
>> >> ****
>> >
>> >Because I perceive that it would be like trying to drag a dead whale
>> >along a beach :-) (You never tried that? I can tell you, its hard work
>> >and slow going!)
>> ***** Acknowledged.
>
>Ah, so you tried pulling a dead whale as well. Funny old world :-)
>
>> ***** I think I was interested in implementation with p2p, because
>> ***** of the degrees of freedom inside an MPI envelope dictated by
>> ***** some kinds of transcations.  These transactions might, for
>> ***** instance, motivate
>> ***** 1) support of more than K contexts (where K is currently like 256)
>> ***** 2) require dynamic contexts which are separate from group ID's
>> *****
>> ***** Hence, by asking how the functions are to be done, I am asking
>> ***** for possible justifications for the more general context model.
>> ***** If hidden contexts are needed to do some of these things, 
>> ***** perhaps they could be justifiably be accomplished with an open
>> ***** context mechanism.  
>> *****
>> ***** That was my motivation.  - Tony
>> *****
>> 
>
>I'll think about these comments, but I suspect there is a language
>barrier in operation here.
>
>Best Wishes
>Lyndon
>
**** Lyndon, we know that these functions will have to be implemented some how.
**** MPI itself might provide such mechanisms as published functionality or
**** hidden functionality.  If published functionality is denied in the
**** standard (eg, general context management) because we cannot justify it
**** properly, but must be implemented internally for most/all complying
**** versions of MPI, then I think we lose out.  My vague way of stating
**** the requirement was to reveal the possibility of this, and thereby to
**** promote such internal degrees of freedom into the public part of MPI,
**** so applications can use them...  Does that help????
**** - Tony