Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!ucsd!ucsdhub!hp-sdd!ncr-sd!ncrcae!hubcap!noao!mcdsun!asuvax!asuvax!nelan
From: noao!mcdsun!asuvax!asuvax!nelan@HANDIES.UCAR.EDU (George Nelan)
Newsgroups: comp.parallel
Subject: Re: parallel numerical algorithms
Summary: Real Parallelism...
Message-ID: <1772@hubcap.UUCP>
Date: 30 May 88 12:25:06 GMT
Sender: fpst@hubcap.UUCP
Lines: 32
Approved: parallel@hubcap.clemson.edu

In article <1696@hubcap.UUCP>, eugene@pioneer.arc.nasa.gov (Eugene N. Miya)
writes:
> In article <1691@hubcap.UUCP> you write:
+ +Anyone care to try for a strict definition?
+
  [etc...]
+ SYNCHRONOUS/SYNCHRONY.  The problem which kills you are side-effects.
+ The early CMU people noted the major problems were: consistency,
+ deadlock, starvation, and exception handling.
  [etc...]

Perhaps, just perhaps, maybe someday, somewhere, someplace, and sometime,
someone will invent something like this:

An infinite, w.r.t. the universe of discourse defined by the data dependencies
of a particular program, MIMD ultra-fine grained side-effect free PARALLEL
machine for IMPLICITLY parallel programs.  I guess no side-effects => purely
functional programs, huh?  Also, it looks like deadlock & synchronization
(consistency) constraints => normal order (lazy) evaluation must be the
computation model of choice [I have some references why this is so --
sufficient interest => I'll post & discuss]; for computational power,
be sure to allow for higher-order functions too.

Oh, BTW, if ya want true scalability, limited (of course) by the definition of
infinity given above, forget about distributed heaps & GC [lambda/combinator
reduction? P'tuey!].  We don't need no steenkin' heaps...

Eductively yurs,
George Nelan, ERC 207, Arizona State University, Tempe, Arizona, USA, 85287
BELL : (602)-965-2791
UUCP : ...{{{ames,rutgers}!hao},{allegra,decvax,ihnp4}}!noao!asuvax!nelan
CSNET: nelan@asu