Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watrose.UUCP
Path: utzoo!watmath!watrose!cdshaw
From: cdshaw@watrose.UUCP (Chris Shaw)
Newsgroups: net.arch
Subject: Re: Yet another language (Occam).
Message-ID: <7393@watrose.UUCP>
Date: Fri, 29-Mar-85 05:26:42 EST
Article-I.D.: watrose.7393
Posted: Fri Mar 29 05:26:42 1985
Date-Received: Fri, 29-Mar-85 06:04:26 EST
References: <202@tekcbi.UUCP> <457@bonnie.UUCP>
Reply-To: cdshaw@watrose.UUCP (Chris Shaw)
Organization: U of Waterloo, Ontario
Lines: 46

> > Occam was a nice try at manual parallel processing.
> > Wouldn't it be nice to apply such techniques as vectorizing, and parallel
> > microcode optimization to a "standard" language such as C.
> > 
> > Having programmed on array processors, multi microprocessor systems, and
> > distributed mainframes, I feel that the best solutions have hidden the
> > parallel nature of the machine.  
> 
> 
> Instead, you need your user to express abstractions, not lower-level
> implementation details of "for" loops, etc.  The higher you go, the 
> better off you are.  Consider three examples:
> 	1) In APL (a language I don't know at all, so I'll fake it)
> 	   if you say
> 		A <- B * C
> 	   where B and C are matrices, then there's an obvious automatic
> 	   parallelism.
> -- 
> 	Joel West

I think that optimizing/vectorizing C is at best a stop-gap measure.
The best you can do (probably) is to use the parallel section of your
machine about 10% of the time.

Besides, one is likely to get hellishly complicated code, both at the user and
object levels. As Joel mantioned, the best way to do parallelism is through
a higher-level abstraction. If one has any doubts, just look at the higher-
level abstraction offered by C/Pascal/whatever as opposed to assembler.

I read a very interesting article about a year ago by John Backus
for his 1978 Turing Award Lecture in August '78 CACM.
The article described the language FP in terms of higher-level abstrac-  
tion and program provability, and although FP isn't exactly something you can 
build device drivers with, it IS a useful first step in a new paradigm of the 
type required to do useful parallel programming.

One would probably be better off in learning a parallel language and using it
on a parallel machine, than one would be in writing half a dozen C/FORTRAN
post-processors to take advantage of your architecture.

The fundamental point to realize, I think, is that one can only adapt a tool
so far (von Neumann-style languages) before you start having to create a
new tool altogether.

Chris Shaw
University of Waterloo