Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!caliban!ig
From: caliban!ig@uunet.UU.NET (Iain Bason)
Newsgroups: comp.parallel
Subject: Re: parallel programming model
Message-ID: <12308@hubcap.clemson.edu>
Date: 15 Dec 90 22:43:55 GMT
References: <12242@hubcap.clemson.edu>
Sender: fpst@hubcap.clemson.edu
Reply-To: caliban!ig@uunet.UU.NET (Iain Bason)
Lines: 95
Approved: parallel@hubcap.clemson.edu

In article <12242@hubcap.clemson.edu> zenith@ensmp.fr (Steven Ericsson-Zenith) writes:
>
>   From: ciancarini-paolo@CS.YALE.EDU (paolo ciancarini)
>   Subject: Re: parallel programming model
>
>   In article <12221@hubcap.clemson.edu> hshi@maytag.waterloo.edu writes:
>   >A naive question:
>   >	We have two parallel programming models: shared memory model via
>   >shared variables and distributed memory model via message passing. 
>   >Is there any model which is some where between? Will it be more suitable
>   >for the persent comptuter architectures?
>
>   A naive answer:
>   >From a linguistic point of view, "Infinite systems exist" (Dedekind). :)
>
>   More seriously, I would say that Linda'a Generative communication
>   through a Tuple Space is different from both.
>
>I can't agree with you here Paolo. In the Linda model processes interact
>via the global associative memory of Tuple Space. In a shared memory
>model processes interact via an addressable global space. In message
>passing processes interact via shared objects (which in some forms are
>dynamically addressable) called "channels" or "mailboxes" or somesuch.
>The behavioral characteristics may differ but what we have here are
>essentially variants of the same model - the persistent nature of the
>intermediary objects being the significant disinquishing characteristic.

I don't see the point of this argument.  The original poster was
looking for a model "somewhere between" message passing and shared
memory.  You seem to be saying that message passing and shared memory
are the same thing at some level, although I'm not sure what level
you're referring to (perhaps that they both share data between
processors?).  In fact, Von Neumann machines and parallel processors
are the same at some level (e.g., they are both digital computers).
These facts don't help answer the question.

>[stuff deleted]
>
>
>   is NEITHER a msg passing model, because agents do not know
>   about each other
>
>Well "agents" "know" about Tuple space and also must "know" about data
>structure and type. This is directly analogous to a "knowledge" of
>communication channels, mail boxes and protocols in message passing.
>
I don't see the point of this argument either.  This "knowledge" is also
directly analogous to a "knowledge" of shared memory addresses and data
structures.
>[stuff deleted]
>
>I hope my view here is clear.
>Linda is a variant of a model I have come to call the "interacting
>process model"(nee MIMD), members of this model are distinquished by an
>associated "interaction model" which captures the means by which
>processes "communicate" and "synchronize" (in this sense Occam, Linda
>and indeed Ease are members of the Interacting Process Model).

That seems like a reasonable point of view.  I think shared memory
parallelism also falls into an "interacting process model".  Of course,
I'm just trying to extrapolate a reasonable definition from the name
"interacting process model".  You may have a different definition.
However, I think the original question asks us to distinguish between
various sub-models of the interacting process model.  If we examine the
differences between shared memory and message passing, I think it is
clear that Linda falls somewhere between the two.  Are you trying to say
that any parallel algorithm can be coded with equal ease in Occam, Linda
or Ease?  How about shared memory?  How about sockets and daemons?
How about remote procedure calls?

I think you raised some interesting questions about how the
implementation of a Linda system affects the design of Linda programs
(I deleted that paragraph -- sorry).  The performance of a parallel
program is obviously going to depend upon the efficiency of the system
services it relies on.  In the case of Linda, the speed some of those
services is strongly affected by the quality of software (e.g., can
the programming tools optimize tuple space transactions into
semaphores or message queues).  However, any portable parallel
programming model has to deal the with the strengths and weaknesses of
hardware.  Different hardware systems have different ratios of
communication capacity to computation capacity.  Many programs are
going to have to decide whether to waste computation or communication
(just as many serial programs have to decide whether to waste
computation or memory).  A balance that is appropriate for a shared
memory machine probably will not be appropriate for a network of
workstations, and vice versa.  As a result, the program cannot be
portable unless the balance can easily be changed. Ultimately, we have
to choose whether the decision on where to strike the balance should
be made by the programmer or the programming tools.


-- 

			Iain Bason
			..uunet!caliban!ig