Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!caip!princeton!allegra!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!srb
From: srb@ccvaxa.UUCP
Newsgroups: net.arch
Subject: Very large memories
Message-ID: <5100120@ccvaxa>
Date: Mon, 1-Sep-86 12:35:00 EDT
Article-I.D.: ccvaxa.5100120
Posted: Mon Sep  1 12:35:00 1986
Date-Received: Tue, 2-Sep-86 21:20:22 EDT
Lines: 52
Nf-ID: #N:ccvaxa:5100120:000:2612
Nf-From: ccvaxa.UUCP!srb    Sep  1 11:35:00 1986


---
Re: recent discussions on the subject of very large memories.

Saying that "you only need as much memory as you can clear in
a second (or some similar measure)" implicitly assumes lots of
things:
    1)	You're doing general computation, and filling the
	memory with code, miscellaneous variables, tables, etc.
	"like people have always done".  Very parochial thinking.
    2)	The access pattern frequencies to memory are reasonably near
	exponential.  I.e., a minority of locations is accessed
	most frequently, with increasingly smaller frequency of
	access to an increasingly large fraction of the memory
	up to a cumulative (100% - epsilon).
    3)	The total time to access the (100%-epsilon) fraction
	of memory is large compared to the time it takes to acquire
	the epsilon from a backing store, and/or some other useful
	work can be done while the backing store is accessed..

It is not hard to think of real applications where one or more of
the above implicit assumptions will be violated.  Large
data bases, tables of pre-computed cryptographic or scientific
functions, real-time tasks where access cannot be predicted but
the data is needed in real-time, and main store backed only by
a slow-seek-time laser disk come to mind.  I'm sure people like
Hector Garcia-Molina can list some more of these for us.

Something a very clever fellow then at Xerox PARC (Thacker) once
said about CPU performance  seems also to hold for memory.
Paraphrasing,
    Sometimes you just plain need it (the above list, for example),
    and sometimes you can use it to substitute for programmer
    effort and implement using simpler paradigms.
An example: virtual memory.  Consider a machine which is running
lots of jobs, and they won't all fit into physical memory.
Technically, you can generally use clever paging strategies to make
the overall time lost to paging appear small.  But if you could just
put all the jobs into memory, you wouldn't even have to HAVE a
paging strategy.  You don't have to be at all clever to get really
good system response and low cost of doing context switches between
processes.  I'd rather be programming my applications on a machine
like the latter, personally.  Programmer time is getting more expensive
and memory cheaper.  No matter how you scale them, it appears that
those two cost curves are eventually going to cross...

Steve Bunch	    Gould CSD-Urbana.    USEnet:  ihnp4!uiucdcs!ccvaxa!srb
1101 E. University, Urbana, IL 61801    ARPAnet: srb@gswd-vms

["The explanatory value of human laziness is often neglected in the study
of the history of man."]
------------------