Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!caip!clyde!cbatt!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!preece
From: preece@ccvaxa.UUCP
Newsgroups: net.arch
Subject: Re: Reasons For Large Main Memories
Message-ID: <5100123@ccvaxa>
Date: Sun, 7-Sep-86 22:04:00 EDT
Article-I.D.: ccvaxa.5100123
Posted: Sun Sep  7 22:04:00 1986
Date-Received: Mon, 8-Sep-86 21:07:44 EDT
References: <8494@duke.duke.UUCP>
Lines: 40
Nf-ID: #R:duke.duke.UUCP:8494:ccvaxa:5100123:000:1796
Nf-From: ccvaxa.UUCP!preece    Sep  7 21:04:00 1986


> /* Written  4:40 pm  Sep  5, 1986 by bzs@bu-cs.BU.EDU in ccvaxa:net.arch */

> Now, ok, you eliminated paging, garbage collection has become a field
> service thing. But, could you do anything useful with all that memory
> and that (relatively) itty-bitty processor? How long would it take you
> to do a MEMQ of a list of a few HUNDRED MILLION lisp objects long?
> etc.
----------
Have you not heard of indexes?  Hash tables?  Arrays?  There are any
number of ways to use memory that don't involve scanning it.  A 2GB
database of bibliographic references (such as Dialog or LEXIS might
have) would run A LOT FASTER if it lived in main memory and wasn't
pounding on the disk interface all the time.  That's not a single-user
example in today's world (it could be eventually, marketed to
libraries and universities), but I have no doubt you can think of
applications that are fully indexed, doing few scans, but using
many, many bytes of data.  The reason you want it in memory is that
you don't know which bytes you'll want or what order you'll want them
in.
----------
> Ok, but still obviously not cost-effective (the magic ingredient that
> gets thrown out whenever this topic starts getting discussed, 1GB of
> memory is going to cost you around $1M
----------
Please allow the user to determine what's cost effective.  If what
you're doing is evaluating huge matrices of seismic data and you
need to do them in N hours because there's a rights auction coming
up, a million may not be an impediment, especially if the machine
can be used as a time-shared engine at times when there isn't a need
for haste.

Betting on those prices holding is about as sensible as betting on
access times holding...

-- 
scott preece
gould/csd - urbana
uucp:	ihnp4!uiucdcs!ccvaxa!preece
arpa:	preece@gswd-vms