Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!apple!sun-barr!decwrl!decvax!zinn!ditka!qiclab!neighorn
From: neighorn@qiclab.UUCP (Steven C. Neighorn)
Newsgroups: comp.sys.transputer
Subject: Re: Transputer vs. i860
Message-ID: <2273@qiclab.UUCP>
Date: 24 Jul 89 08:27:26 GMT
References: <8907181536.AA13030@sdsu.edu>
Reply-To: neighorn@qiclab.UUCP (Steven C. Neighorn)
Organization: Qic Laboratories, Portland, Oregon.
Lines: 91

In article <8907181536.AA13030@sdsu.edu> davidson@SDSU.EDU (Craig Davidson) writes:
>What I meant was the CSP (Communicating Sequential Processes) model of 
>programming distributed memory systems.  This is directly implemented in occam
>and in hardware by both the Ncube and Transputer processors.  All the
>hypercube machines and their operating systems use this parallel 
>processing model as well.  Most versions of C, Fortran and Pascal that I am
>familiar with on distributed memory machines also have followed the CSP model.
>Even Ada (through rendezvous etc) and Linda are CSP based systems.  It is the
>CSP architecture which is elegant.

Then I wish you would have said CSP was the concept that was elegant and
probably the best for large parallel processing systems. But I'm not sure
I entirely agree with your conclusions about CSP being the basis for machines
other than Transputer machines, though it may be a problem with semantics
more than anything else. I don't look at hypercube's loosly coupled MIMD
architecture or Ncube's architecture as being specifically CSP-based, as
defined by Hoare. Yes, processes run in distributed memory partitions, and
yes, those processes communicate with each other at varying speeds, 
depending on implementation, but do they fully fit the CSP model? I look at
CSP less as a generalized description of parallel computation and more as
a mathematically sound paradigm that covers conventional sequential programming
within a communicative parallel environment. The beauty of CSP is the
mathematics, the handling of nondeterminism, and the application towards
systems of processes. I fail to see how the key points and beauty of CSP
are fully applied in the hardware or software you discuss above, except
for the Transputer and Occam. Occam follows the CSP guidelines closely, and
the Transputer is a natural home Occam. But the others? If I'm way off
base here, I'd like to find out in the friendly, learning environment
of USENET rather than the hostile accommodations of a post-final exam
computer science debate at the local watering hole.

I also don't understand what you mean when you say that most versions of C,
FORTRAN, and Pascal on distributed memory machines follow the CSP model.
How so?

Ada is obvious to me, with rendezvous as you mentioned, along with priority.

>Floating Point Systems T-series market penetration would have been as bad 
>if they had offered C without reals or multi-dimensional arrays, with 
>no assembler or instruction set reference manual, no standard numeric 
>libraries and no operating system.  The example of Floating Point Systems
>is also a reaffirmation of what I was trying to say, that is Inmos has been
>reluctant to work with third party developers to produce industry standard
>languages such as C or environments close enough to UNIX to be used. To
>their credit they are much better now.  I was also trying to point out
>that Intel is learning faster than Inmos.

I don't like to see any chip and/or its manufacturer die because its
marketing department doesn't know what the Hell its doing. Chips should
die because they are outclassed, used up, or beaten by something
better on the market. If Intel's marketing is better than Inmos', then
I hope Inmos gets their marketing people gets on the stick. If Intel's
chip is better than Inmos', then I hope Inmos gets their engineers on
the stick.

>Charles L. Seitz's comment that occam was "... the Fortran of parallel 
>processing" is not necessarily a negative comment.  Occam is a start, it has
>the control structures necessary for parallel processing and it is something
>to build on.  Even Tony Hoare and David May would agree with Charles Seitz
>and do not claim that occam is the ultimate parallel language, only a
>useful beginning.  As to Fortran, last I looked vendors are now starting 
>to offer Fortran-88, how many languages have, or will, survive for over 
>30 years with the popularity of Fortran.  The Ncube, Intel, and Amatek
>hypercubes all offer Fortran, why not the "Fortran of parallel processing?"
>Since Charles Seitz was brought up, does anyone have the article 
>reference where he describes the hypercube chip he is designing?

Lest I also dip into the realm of good/bad FORTRAN arguments, let me just say
that FORTRAN-88 and 30 years of popularity are not necessarily a good thing.
In fact, some people who are trying to move programming languages into the
90's might even say they were a bad thing. FORTRAN is popular because it
*was* popular. No one wants to go back and tear apart that hundred-thousand
line simulation and convert it into something a tad bit more modern. It has
a long history, and it was right there at the beginning, and '88 makes some
nice improvements, but FORTRAN and goodness just on the basis of longevity
aren't going to wash with me.

Why do companies line Ncube, Intel, and Amatek offer FORTRAN? Because they
would be foolish not to. I mean someone's got to handle those old versions
of QUANC8. I know there is a place for the language, but tell me are there
any inherent properties in FORTRAN that make it suited for parallel
programming *besides* its history?

I can't say whether Charles Seitz's comment really was meant as an insult
or a compliment. In the context of the article, it was definitely an
insult.
-- 
Steven C. Neighorn           !tektronix!{psu-cs,nosun,ogccse}!qiclab!neighorn
Sun Microsystems, Inc.      "Where we DESIGN the Star Fighters that defend the
9900 SW Greenburg Road #240     frontier against Xur and the Ko-dan Armada"
Portland, Oregon 97223          work: (503) 684-9001 / home: (503) 641-3469