Subject: new proposal

From: [email-masked]
Date: Mon, 22 Mar 93 00:11:50 PST

Tony and Lyndon,

I will respond in a separate message to some of your detailed
comments on Proposal V.

But maybe we can move faster by popping up a level.

It seems to me that 
  you like the idea of cacheing arbitrary info in group descriptors, 
  you like the idea of groups as things within which contexts get formed,
  you like performance guarantees, and 
  you don't like having to use opaque id's in point-to-point communications.  

I'm not quite sure whether static groups and synchronous group control
are OK, but I'll presume here that they are.

Well, this is pretty neat.  If this keeps up maybe we can converge
on just one or two proposals.

Most of my gripes with other proposals have been based on performance
and/or a need for asynchronous servers (with attendant performance
and non-portability gripes).  But I notice that explicit performance
expectations have been gradually appearing and the need for servers
disappearing from other people's proposals.

Perhaps it is time for a synthesis.

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.

Conceptually, I like this better than proposal V.

Do we already have a proposal like this?  Should we have one?

In general, do you guys buy off on the concept of including performance
expectations in the specification?

A couple of discussion points...

1. The separation of group and context is defensive.  I think I
understand what it means to copy a context.  I am not sure of either
the functional or performance implications of copying a group.  E.g.,
does cached info get copied?

2. I will respond here to two criticisms that have been raised against
the cacheing facility.

Lyndon notes
> % I like the general idea, but I'm nervous about two things:
> % (a) implied associativity of group descriptor cache - this
> %     will potentially be time expensive in implementation.
> % (b) there is no method proposed for abritration of keys
> %     between independently written modules, so we are 
> %     in the same problem regime as just having message tag 
> %     and no message context.
> %     However, key's are local, so presumably you would find 
> %     it acceptable to add a key registration service?

I implicitly proposed a key assignment service in my long-ago example.
It said in part:

   static int gop_key_assigned = 0;    /* 0 only on first entry */
   static MPI_key_type gop_key;        /* key for this module's stuff */
   ...
     if (!gop_key_assigned)     /* get a key on first call ever */
     { gop_key_assigned = 1;
       if ( ! (gop_key = MPI_GetAttributeKey()) ) {
         MPI_abort ("Insufficient keys available");
       }
     }

This is not really "registration" because nothing goes into the
key assignment routine except the number of times it's called.
But assuming that each call site is protected by a separate 
variable, the effect is to register the call site.  As Lyndon notes,
this is highly local.  But it also allows the returned keys to
have their values restricted so as to permit rapid testing and/or
retrieval.

Tony notes
> %**** Stripping is extremely controversial aspect, and arbitrary.
> %**** If the recipient has the methods with the same name, then
> %**** a new rendezvous could be accomplished at the far end

Yes, stripping is arbitrary.  My motivation is that this greatly
simplifies the design and satisfies what I view as the most critical
need: to make collective comms run fast without complicating the
calling sequence.

I have no objection in principle to extending the facility to include
classes of information that do not get stripped.  But I sure didn't
want to try creating and selling a spec that would handle, e.g.,
heterogeneous systems.

Enough for here -- what do you think of "proposal VI" ?

--Rik

----------------------------------------------------------------------
[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