Xref: utzoo comp.sys.next:456 comp.society.futures:664
Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!encore!bzs@encore.com
From: bzs@encore.com (Barry Shein)
Newsgroups: comp.sys.next,comp.society.futures
Subject: Re: NeXT not revolutionary enough?
Message-ID: <4069@encore.UUCP>
Date: 1 Nov 88 19:30:14 GMT
References: <471@wucs1.wustl.edu> <4391@ubc-cs.UUCP> <485@wucs1.wustl.edu>
Sender: news@encore.UUCP
Reply-To: bzs@encore.com (Barry Shein)
Organization: Encore Computer Corp
Lines: 53
In-reply-to: conrad@wucs1.wustl.edu (H. Conrad Cunningham)

From: conrad@wucs1.wustl.edu (H. Conrad Cunningham)
>In article <4391@ubc-cs.UUCP> manis@grads.cs.ubc.ca (Vincent Manis) writes:
>> ...Basically, the 
>>issue for `revolutionariness' is not the operating system, but the under- 
>>lying physical architecture. ...
>>...
>>It's clear that the leverage we need for truly revolutionary applications 
>>comes from massively parallel systems, either loosely coupled (in a network) 
>>or tightly coupled (e.g., Transputers or the Connection Machine).  ...
>
>	I have no disagreement that wide-scale availability and usage of
>massive parallelism is one of the potential revolutions somewhere over
>the horizon. Innovative computer and communications architectures and
>designs must play a big part in that revolution.  However, without
>devising new ways to exploit the parallelism on a wide-range of
>problems, all the fancy parallel hardware won't be so revolutionary.
>The revolution will be as much--maybe moreso--a "software" revolution
>than a "hardware" revolution.  New languages, operating systems,
>tools, theories, methodologies, algorithms, and/or techniques are
>needed.

First off, consider the company I work for (and also note I was saying
the same as I am about to say before I came here a few months ago,
don't confuse cause and effect.)

The problem with both of the above comments is that they are making
the "best" the enemy of the "good".

I have no doubt that all of the above coming true will make massive
parallelism more useful, but to some extent this whole line of
reasoning is a thought virus, something which infects your thinking
about a new idea and renders your thoughts nearly useless.

Non-massive parallelism is here *today* in completely useful
packaging.  Why does something as simple as knowing that while your
compile is running in the background your foreground is running on a
different CPU so response remains flat. Also, with several CPUs,
things like compiles of lots of files can speed up at least linearly
(at least seems odd until you realize how efficiently the buffer
caches and shared text segments can get used during parallel compiles,
they're not only cpu bound but use a lot of disk resources as well.)

Also, traditional unix pipes like:

	lastcomm | sed mumble | sort -u | wc -l

will run in parallel on 4 (in this case) CPUs.

There are a lot of other examples, like I said, don't make the best
the enemy of the good and say "Ah, computers are useless, no one has
even solved the halting problem yet!" which is what a lot of this
moaning and groaning sounds like.

	-Barry Shein, ||Encore||