Subject: Agreeing with Rik

From: [email-masked] (Jon Flower)
Date: Fri, 5 Mar 93 19:25:16 PST

I fully agree with Rik Littlefield's comments and am very worried 
that we are running out of time. 

My personal preferences at this point would be to prioritize 
various things as:

a) Get collective communication down properly. Include all the (blocking)
   routines that applications could benefit from - even obscure ones.

b) Try to agree on some minimal way of creating a program and 
   identifying a process in it.

c) Define point-to-point message passing.

d) Worry about "other things" like dynamic process models and 
   non-blocking concatenate and its friends.

I put collective communication ahead of point-to-point in my list because
I am EXTREMELY concerned about the complexity of the current point-to-point
design. 

My feeling is that a complex point-to-point layer is only important
if it allows applications to be written that execute faster than
they would with a simpler layer. 

In my experience, especially with number-crunching programs, 
users most benefit from highly optimized collective communication 
routines, not a vast array of point-to-point routines. 

One might argue, of course, that the sophistication in
the point-to-point layer is exactly so that implementors can make
highly optimized collective comm. layers. I don't agree with this
for the simple reason that I don't think it's obvious that any 
particular layer in the point-to-point spec. is faster than any
other. If this is so I would imagine that collective communication
calls will be optimized independently for each machine (as they are
now) rather than being built "portably" from the point-to-point 
layers. Thus the sophistication in the low level is probably 
wasted. Of course, many people will want to build their codes from
simple point-to-point routines, but I wonder if this doesn't just
mean that we're missing some important collective ones, at least
in some cases.

To respond to one of Al Geist's comments it bothers me too that
we seem to be accepting vast quantites of point-to-point stuff
that certainly isn't current practice (some of it doesn't even
exist in any other system) and yet are wary of adding things 
like smart collective routines and toplogy support that are 
in day-to-day use in a lot of applications.

	Jon Flower

p.s. By the way, my vote would be for opaque task ID's for 
     hypothetical forward-compatibility, ..... but I think they're
     a royal pain to use!! 

     In every case where I've had to do this I've ended up 
     making an array in each node, collecting the opaque ID's 
     and converting them to consecutive integers.