Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site bonnie.UUCP
Path: utzoo!watmath!clyde!bonnie!jww
From: jww@bonnie.UUCP (Joel West)
Newsgroups: net.arch
Subject: Re: Yet another language (Occam).
Message-ID: <457@bonnie.UUCP>
Date: Fri, 29-Mar-85 01:47:38 EST
Article-I.D.: bonnie.457
Posted: Fri Mar 29 01:47:38 1985
Date-Received: Fri, 29-Mar-85 06:02:18 EST
References: <202@tekcbi.UUCP>
Organization: CACI -- La Jolla, Calif.
Lines: 51

> 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.  By hiding the parallel nature, I mean
> removing the need for parallel constructs, yet providing multi-processor
> performance advantages.

I would agree with "manual" vs. "automatic" parallelization.  However,
if taking FORTRAN DO loops and vectorizing them were easy, Illiac IV
would have been a raging success.  C is much, much worse, because it
encourages you to get to the byte-level and also use neat, compact
tricks of side-effects.  Attempting to examine a low-level algorithm
is a fairly significant artificial intelligence problem.

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.

	2) In some database or artificial inteligence language, you say

		for each HACKER with PC.TYPE = "IBM"
		    compute SQUANDERED as the total of SOFTWARE.INVESTMENT

	   obviously you can let loose on all the database in parallel
	   and somehow merge running subtotals into a total

	3) In discrete simulation, many things go on in parallel in the
	   real situation you model (4,000 assemblers in the factory, etc.)
	   so you can express each one (of a class) and let the event
	   scheduler run them in parallel.  This works quite nicely if
	   things are loosely coupled -- guy A doesn't change guy B at
	   time 100, but instead at time 100, guy A sets up a change
	   for guy B at time 101.

The last is a situation I've investigated in some detail and I believe
it is quite feasible to crack.
-- 
	Joel West				     (619) 457-9681
	CACI, Inc. - Federal 3344 N. Torrey Pines Ct La Jolla 92037
	jww@bonnie.UUCP (ihnp4!bonnie!jww)
	westjw@nosc.ARPA

   "The best is the enemy of the good" - A. Mullarney