Subject: Some points for the introduction

From: Steven Ericsson Zenith <[email-masked]>
Date: Mon, 23 Nov 92 17:29:37 -0600

In your draft

	"One of the most widely used paradigms for programming parallel
	machines is that of message-passing."

I'd like to see this changed to "Message passing is a paradigm used
widely on certain classes of parallel machines; especially those with
distributed memory."

	"it must provide a simple, easy-to-use interface for the basic
	user while not semantically precluding the high-performance
	message-passing operations available on advanced machines."

Can you give an example of what you mean by "high-performance
message-passing operations available on advanced machines" - I have
difficulty imagining the conflict you describe.

	"The attractiveness of the message-passing paradigm at least
	partially stems from its wide portability.  Programs expressed
	this way can run efficiently on shared-memory multiprocessors,
	distributed-memory multiprocessors, networks of workstations,
	and combinations of all of these."

This is contentious. The statement is false if you keep in the word
"efficiently" and true otherwise.

Message passing has proven to be a difficult addendum to existing
programming practices primarily because it preoccupies the programmer
with issues of data distribution.  Message passing is unsuitable, in my
experience, as a general purpose model for parallel programming.
Programmers using the model become preoccupied by issues of data
distribution.

Forget for the moment issues of mapping programs to hardware topology.
The programmer using a message passing model is forced to consider, in
some detail, multiplexing and routing issues when distributing data
among groups of processes.

Generalized message passing does not map well onto the range of parallel
machine architectures for a general set of applications.  The semantics
of most message passing systems compel an implementation to copy data
that might otherwise be passed by reference. Exchange by reference in
message passing produces side effects that most programmers do not
consider and specializes the program (I'm not saying we shouldn't
include such facility).

However, I recognize that message passing is an easy concept to sell -
since we defined Occam (I was one of the principal people involved with
that language design) I've spent the past 8 years writing and watching
other engineers write message passing programs. I still write message
passing programs myself - I'm an implementor of higher level
abstractions (in this regard I've used Express), a compiler writer (I
want to target this standard) and I also write code for embedded systems
(robots etc..  in Occam and C). I believe that the first order audience
for this standard are really people like me - specialists, not general
purpose high level algorithm designers; i.e. generally not chemists and
physicists, excepting those currently forced to use such machines by
their proximity to them.

There is a distinction between message passing as a component of
parallel/distributed machine systems architecture and generalized
message passing as a programming model and I would like us to focus on
the former rather than the latter since that is where I see the need and
we can leave the other debate to some other time and place. We should
take a noncommittal stance; i.e. whether or not message passing is THE
way to program parallel machines, standardization of message passing is
an important and useful activity.

The only other comment I have concerns the list of items included in the
standard. You say

     o  A simple way to create processes for the SPMD model

I think this is loaded with problems for reasons I mentioned at the
meeting; i.e., it introduces more complexity and opportunity for
deadlock etc.. I would rather not see us say too much about the process
model at this stage; except to say that there is some process model
defined by the language using the standard and to say something about
side effects between processes that affect the message passing semantics
(i.e., that there should be none).

Regards,
Steven