Path: utzoo!attcan!uunet!samsung!uakari.primate.wisc.edu!uflorida!haven!purdue!tippy!sawmill!mdbs!zed
From: zed@mdbs.uucp (Bill Smith)
Newsgroups: comp.arch
Subject: Re: Teradata
Message-ID: <1990Oct7.131537.23798@mdbs.uucp>
Date: 7 Oct 90 13:15:37 GMT
Organization: mdbs, Inc.
Lines: 81

This reply pushed one of my buttons.  I'll try hard to be civil.

>This is not necessarily clear.  There are various penalties
>associated with shared memories, including performance and cost.

There are various penalties involving performance and cost associated 
with *everything*.  That's why design is an interesting problem.

>>Sharing allows some nice programming techniques, and makes a
>>difference when trying to port a lot of software to the new machine.

>Granted, most parallel software was written under the shared memory
>model, and if the main constraint is porting existing software, then
>shared memory machines win. This argument was used in the past
>on various innovations.

What ever happened to software engineering?  If "most parallel software
was written under the shared memory model", it is, by definition, not
portable.  If it is not portable then, in the long term, the software will
cost more to keep than to toss it today and start over with a better
software model.  Why don't sponsors of large projects demand, in the 
requirements, that the project be developed in a fashion that will port 
to advances in architecture technology that might be reasonably expected 
in the next 10 (or even 5) years?  It doesn't make any sense considering how 
expensive software is.   The Kale's Chare Kernel is one current research 
project that I am familiar with that doesn't care what what the architecture 
of the computing engine is.  I'm sure there are more.  It's taken for 
granted that we don't write software that depends on whether the processor 
was implemented in CMOS, TTL, E2L or I2L.  Why can't this principle be 
extended to the next, IMHO, obvious level?

>While sharing at the page level across a network works, increasing
>the number of workstations to say, 1000, will seriously impede
>performance.

Well, then find a better way to get 1000 nodes to cooperate!

>I disagree.  Shared memory automatically creates contention at
>for frequently used data.  Caching is a possible solution, but 
>cache coherence protocols for fine grained machines become incredibly
>complex, and further impact performance.

Again, find a better way!  If you get too much contention on frequently
used data, design algorithms that don't have any frequently used data.
If cache coherence protocols are incredibly complex and impact
performance, design an architecture that doesn't need multiple caches 
on a single piece of physical memory.

>Further, shared memory does not obey the natural laws of physics,
>in a sense.  

A law of physics is "natural" if it's been around long enough that we've
forgotten how much turmoil its discovery caused.

>The abstract shared memory model pretends that there
>is a large number of communication paths to a single point. This
>simply isn't true, and additional hardware is required to provide
>this illusion to the programmer. This hardware costs time and
>dollars.

>Parallel programs designed to reflect the underlying physical
>reality will operate faster than those that work in a virtual
>model. I suppose an IMHO is in order here.

At first, I thought these two paragraphs said valid points, but after
rereading them, I realized that they deny the entire history of
operating system research.  The whole point of a software engineering
environment is to hide as many details of the underlying physical reality
as was possible to hide at the time the environment was developed.  Consider
demand paged memory, NFS, Internet, pre-emptive process scheduling, 
standard device driver interfaces, etc.   The performance issues are not
only denigrated, but the whole point is that if the computer does more
work, the humans won't have to.  The essence of Computer Science is
illusions for programmers and users.

>Mike Bolotski          Artificial Intelligence Laboratory, MIT
>misha@ai.mit.edu       Cambridge, MA

Zed
sawmill!mdbs!zed
Standard disclaimer.