Path: utzoo!attcan!uunet!super!kuehn
From: kuehn@super.ORG (James T. Kuehn)
Newsgroups: comp.arch
Subject: Re: Is Shared Memory Necessary?
Keywords: latency; access time; memory, shared
Message-ID: <471@super.ORG>
Date: 19 May 88 17:53:18 GMT
References: <503@xios.XIOS.UUCP> <2676@pdn.UUCP> <674@cernvax.UUCP> <685@thalia.rice.edu> <8125@pur-ee.UUCP> <29577@yale-celray.yale.UUCP>
Sender: uucp@super.ORG
Reply-To: kuehn@super.UUCP (James T. Kuehn)
Organization: Supercomputing Research Center, Lanham, Md.
Lines: 24

In article <29577@yale-celray.yale.UUCP> lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) writes:
>
>If I am to give my personal opinion on very large scale global address space
>machines, then it is that I think they must provide local, fixed routing
>between close processors as an alternative addressing mode. The generality
>of the global address scheme will always have to be paid in long access time
>compared with local access.

Not necessarily.  The confusion seems to be that you are making
large global address space synonymous with long, fixed access time.  
Consider the Denelcor HEP, which was Hank's first example.  
It had a large global address space and a variable memory access time 
that depended on the distance from the processor (number of network hops).
If your compiler knows about memory hierarchies and can distinguish
"near" addresses from "far" ones (in terms of latencies), it can schedule
values accordingly.  The flat, shared address space makes life convenient
for the compiler, especially when it doesn't know where to schedule a value.
If in addition, you have a machine that hides latency by some technique
(as did HEP), you're home free.  In summary:

Reducing latency is always a win, but when you don't know how, hide it too!

Jim Kuehn
kuehn%super.org@sh.cs.net