Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!lll-tis!lll-winken!spl1!laidbak!lm
From: lm@laidbak.UUCP (Larry McVoy)
Newsgroups: comp.arch
Subject: Cray & Amdahl Virtual memory debate
Message-ID: <1534@laidbak.UUCP>
Date: 24 Jul 88 23:39:10 GMT
References: <4232@cbmvax.UUCP> <76700035@p.cs.uiuc.edu> <5342@june.cs.washington.edu> <537@ns.UUCP>
Reply-To: lm@laidbak.UUCP (Larry McVoy)
Organization: LAI Chicago
Lines: 35

In article <537@ns.UUCP> ddb@ns.UUCP (David Dyer-Bennet) writes:
>In article <5342@june.cs.washington.edu>, pardo@june.cs.washington.edu (David Keppel) writes:
>> Relevant (really?) question: Does it make more sense to buy a little
>> bit of very fast memory and slow it down with virtual memory, or to
>> buy a whole bunch of fast physical memory and slow it down by putting
>> it farther away?  (Assume: $ is no problem).  
>                     ^^^^^^^^^^^^^^^^^^^^^^^ 
>  Obviously :-) the correct solution is to buy a whole bunch of VERY
>fast physical memory.  A cache system (I consider virtual memory to be
>essentially a caching system) is never as fast as an entire main
>memory made out of that same technology.

Here's something else that we all may be passing over too lightly: 

    Virtual memory does more than offer a "solution" to the 
    too-large-code problem.  In addition VM provides

    + protection (Cray has a poor man's base & bounds)
    + relocation (ditto)
    + sparse address space (an example you all should know,
      and one Cray doesn't care too much for, is the standard
      unix process which is [text:data:heap->  :empty:  <- stack].
      Cray doesn't have the luxury of that empty space; I've heard
      that they interleave the heap & stack.  Gag.)
    + what I call VVM (virtual virtual memory hooks.  If you 
      want to simulate shared memory (across any communication
      channel) one way to do it is to use the MMU to catch writes
      and then schedule a flush.  (You can adjust the out-of-sync
      time by adjusting the delay to flush).  For more on this see 
      the Mach papers, they have tried something similar.

I'd be interested in seeing this discussion incorporate these issues
into the debate....  
-- 

Larry McVoy      (laidbak!lm@sun.com | ...!sun!laidbak!lm | 800-LAI-UNIX x286)