Subject: Be brave. Be sure.

From: Steven Ericsson Zenith <[email-masked]>
Date: Fri, 5 Feb 93 10:16:22 -0600

Thanks Jim (or is it Paul) for the name correction (via private mail)...

I know what I'm suggesting - and yes, though I hate to admit it, it is
the Occam model more or less. Though you shouldn't allow your distaste
for the language to deflect you from the qualities of it's communication
model. The inadequacies of that language are many but when it comes to
the communication model (CSP) it is fundamental. All I'm suggesting here
is that we do not make the other mistake, that of providing so much that
it is neither managable by us or our intended audience.

Either we are prepared to provide something better than currently exists
based on a good understanding of our collective experience with mature
concepts or we should start from an existing system, with all its flaws,
and work from there.  This is not a forum for invention.

I should qualify my comments to reiterate that in fact I am looking to
this forum to provide a consistent interface for low level
implementation in operating systems and code generation. I never want
any of my general purpose users using message passing as a means to
program machines. And if you gave me just processes and blocking send
and receive that *would* be enough.

As someone who has written many message passing programs (using Express
and other libraries, as well as Occam and CSP), and made it my business
over the years to talk to others who have, I have to tell you that the
fewer well conceived choices you give me the happier I am and, in my
experience, the user is.  I just don't believe those people who say we
have to provide every form - it is counter to all my experience with
users (no doubt, there are users here who will insist on being provided
with every variant ;-) - but you will have seen that manifestation
before. ).

One way to look for evidence to support or denounce this is to undertake
an investigation.  Find an array of *applications*, not systems tools
etc.  but "real" applications, and identify the subset of functionality
used.  My bet is that you will discover the subset is small, the place
where non-blocking communication is used is on machines where the
process model implementation is inadequate, and that code that does not
fit into my simple model is not readily portable.

Steven

---

From: [email-masked] (Stephen R. Wheat)
Date: Fri, 5 Feb 93 12:06 MST

Steven:

While I am impressed that you have enough influence over
your users to convince them that they need not see the messaging
environment themselves, I must confess that I am not so
fortunate.

My users are developing their codes in C, F77, and C++.
The current trend here at Sandia is towards C++.  Our REAL
codes (REAL code is one that we make money off of, hence
very important :-) are done by those that are still waiting
for compilers to do everything.  But, while they continue to
wait, their livelyhoods depend upon their ability to get
the best performance from these MP beasts as possible.
Even assembly language is still a useful tool for them,
case in point: tuned libraries where interfaces are defined
but the library code is certainly not portable.

In addition, it is my opinion that there is way too little
experience with compiler generated messaging to have such
a concept meet the "maturity/experience" criteria upon which
we wish to base MPI.

As for overlapped messaging, I dare say that EVERY code here
at Sandia makes use of overlapped messaging.  At the very least,
the programmers want to have multiple I/O channels active
simultaneously, which is at least possible on our two
1024-processor nCUBE 2 hypercubes.

Furthermore, it is clear that my users are already digging
into what possibilities for performance enhancements
await them in our new Paragon.

These are general users! Not just the wizards.
Again, the "food chain" is quite clear.  We do want simply understood 
features for the "novice" or "don't care" people.  However,
we must have what the experienced general users want.
Furthermore, we must have the "buy-in" of the wizards.

To make this more clear, I use the term wizard to refer
to application types doing real, dollar/pound income-oriented
work.  That is, they are not of the CS lunatic fringe type, but are
real-world applications people.

All of this is just to state that the standard should
be primarily for human use, not for compilers only.

As has been voiced by others, I strongly suspect that
overlapped I/O and computation is a feature that general
users will (AND DO) want.  Furthermore, I believe that
"our collective experience with mature concepts" can tackle this
problem in a very successful manner.

Stephen

---

From: Tony Skjellum <[email-masked]>
Date: Fri, 5 Feb 93 15:58:52 CST

To follow up on Stephen's comment, I do not believe that compilers would
make good use of this standard.  Active-message-level programming seems
a much better level for standardizing compiler interfaces.  

- Tony