Subject: Be brave. Be sure.

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

From: [email-masked] (Stephen R. Wheat)

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

The fact that your users are programming using message passing suggests
that they are certainly also prepared to use assembler when necessary.
The reason they use MP is the same reason they use assembler at times:
there is no higher level way currently to achieve what they want with
the performance they require on the machines they are using. ;-) Evenso,
when I've asked people (physicists and so on) with some experience
programming such machines this question they have confirmed that they
use MP as reluctantly as they use assembler - it's just that sometimes
it's unavoidable. Some of those people are at Sandia. I certainly would
not want to deprive them of their lively hood and there are exceptions -
of course.  Some people really enjoy the challenge of writing MP code,
just as they enjoy the challenge of writing assembler - me too at times
;-)

But the pro's and con's of message passing as a programming model, and
the alternatives, are not the issues here. While we may have different
motivations we do all understand the importance of MP at some level.
Certainly it should be usable by "users" in the absence of anything
better. In fact I'd contend that my recent calls serve those that do
have to use it well - wizard or not.

I am not calling for us to take power away from users - on the contrary
- I'm calling for greater utility and usability through simplicity. I am
calling for us to focus on things we understand well and to avoid
invention. I do not feel that such simplicity will fail to serve wizards
- your implication is that wizards are only attracted to complexity:
this surely is not true.

    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.

No argument here - but then this isn't an objective of MPI.

    As for overlapped messaging, I dare say that EVERY code here ...

I am not saying that non-synchronizing send is a "bad thing" - I am
saying there is a simpler way of looking at these things. Define the
fundamentals and work from there. We have been arguing about the nuances
of buffer behavior without getting a real feel for our base objectives.
You can build all you want - if you really want it - with fundamental
and well understood components - it makes a great opportunity for third
party software vendors like Parasoft and DSL. Buffering characteristics
are likely to remain a choice based on hardware design and we should
leave such things alone in our interface design.

Now I understand that most machine vendors have a variety of approaches
- and that is exactly why we should should be careful. But I cannot
believe the solution for MPI is the union of those approaches - though
it may be some component of the intersection.

Isn't our objective to provide a Message Passing Interface that will
allow people who want to write portable (or transportable) MP code to do
so? And to provide for compiler writers and architects - people like me
- who are just looking for a consistent interface on MP machines?
Doesn't usability have a right to be at the fore of our concerns?  If
this is the case then we do need some well conceived abstraction or we
must adopt an existing system and refine it. When it comes right down to
it, I really don't mind which.

I would like though to take a program written in MPI and simply
transform it into another MPI program for execution on a machine with
different characteristics. What I've seen so far is going to make it
very very hard to do that. I'm only likely to want to do literal
translation on a machine identical to the original target - it would be
nice to permit simple transformations and checking (for deadlock for
example) ... wouldn't it?

Incidently, in addition to my architects point of view I do still
design message passing systems and program them - so I hope I qualify as
a user too. ;-) 

Steven