Subject: So many proposals, so few standards...

From: [email-masked] (Al Geist)
Date: Thu, 4 Mar 1993 09:47:36 -0500

I just wanted to put in my endorsement for Bill and Rusty's
proposal to have three levels. The lowest having Marc's
init, start, wait, free, etc. constructs.
The next level having send and receives using buffer descriptors.
The highest level send and receives specify the buffer and the datatype
and send only contiguous bytes.

I also like the idea of having opaque task id. This has been brought up
by Peter, Tony, and now Bill and Rusty. There are nice features that
arise from this approach that makes computing in a dynamic, heterogeneous 
environment much easier and efficient. PVM has now gone to this
method of task naming because of the advantages.
There is still a need for users to think in terms of 0-[p-1]
and this is logically provided by having a rank in a group.

I also agree with Bill and Rusty that to write portable code
we have to have a standard way to start up one or more tasks.
The existing interfaces all provide some mechanism for doing this.
Are we going to propose a standard that doesn't even provide
some of the basic features of the exiting interfaces?

With regard to opaque task id, spawning tasks, and dynamic groups,
I see a double standard being applied that I do not like.
When we discuss communication routines, many people vote for
new totally untried (maybe unworkable) concepts because
"they could lead to more efficient programs in the future."
Fine. But when we talk about things like dynamic groups,
people start saying "gosh, never been tried before. We better not do it."
Some of our standard effort is future looking and other parts
are backwards looking. I feel it is time to try to be consistent.

One final thought. If we do not design an interface that is
as flexible, intuitive, and easy to use as existing interfaces,
then we will have simply created Yet Another Message Passing interface (YAMP)
and not a standard.

Al Geist

---

From: Tony Skjellum <[email-masked]>
Date: Thu, 4 Mar 93 10:11:41 CST

I concur with Al.
- Tony

---

From: L J Clarke <[email-masked]>
Date: Thu, 4 Mar 93 16:19:30 GMT

Okay, this is mainly about task identifiers again.

[stuff deleted]

> and this is logically provided by having a rank in a group.

if (MPI will provide process groups) 
then
  One thing processes do really find useful - from hard experience -
  is to be able to receive a message from any member of the process
  group.
  If we frame point-to-point in terms of some opaque (global) task
  identifier type then how can we provide the very expressive 
  receive selection above?
  If we can't, then opaque types do not seem capable of providing
  expressive power for process groups.
fi

> some of the basic features of the exiting interfaces?

Either
one includes the task creation in the source code of the program
in which case MPI somehow ought to look at a mechanism compatible with 
the overall conceptual content of MPI
Or
one puts the task creation outside the program and outside the domain of
MPI. 

This also seems to boil down to whether we have a dynamic process model
or a static process model. When we decide this then we can look at the
details, but I really do think MPI should agree which the goal is before
trying to reach consensus on the attack plan. 

Why don't we email vote on this? My vote: static model.

> "they could lead to more efficient programs in the future."

Can we find examples of this? Let me see off the top of my head ...

a) Communication handles, unless I missed somthing.
b) Ready sender communication (symmetry partner of ready receiver)
c) Buffer descriptiors with data types

> are backwards looking. I feel it is time to try to be consistent.

Unfortunately it is the burden of a standards committee that it should
standardise only agreed existing practice, in such a manner that
imminent developments are anticipated and a route for extension of the
standard at such a time that such developments become common practice is
practical, insofar as the standards committee is able to so do.  My
phrasing may not be the best, but the principle should be perfectly
clear. 

> then we will have simply created Yet Another Message Passing interface (YAMP)

i.e., it will not be acceptable to a sufficiently large portion of the
market and therefore will not be accepted by the market as a 'de facto'
industry standard. How about some serious suggestions regarding how MPI
can ensure to avoid this apocalypse?

Best Wishes
Lyndon

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