Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!ames!pacbell!att!cbnewsh!wcs
From: wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 erebus.att.com!wcs)
Newsgroups: comp.arch
Subject: Re: 64-bit addresses
Keywords: Too Much is Never Enough!
Message-ID: <8656@cbnewsh.ATT.COM>
Date: 5 Mar 90 07:35:49 GMT
References: <11227@encore.Encore.COM>
Reply-To: wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 erebus.att.com!wcs)
Organization: News Busters at AT&T Bell Labs
Lines: 35

In article <193@zds-ux.UUCP> gerry@zds-ux.UUCP (Gerry Gleason) writes:
>... how many MIPS does it take before you can process a 4G space...
> I think we're a still far from that point.

5 or so years ago, Peter Honeyman and gang at Princeton were
building the "Massive Memory Machine Project" to find out what you could
do with lots of memory if you could afford it.  They had a toy machine,
which they didn't consider massive, which was a VAX with 128MB.
(Unfortunately, they had bought DEC memory instead of third-party,
so they were paying through the nose for maintenance, but....)
Today, 128MB costs about $12.8K, and 4GB costs about $400K - at that
cost, a lot of people can find fun things to do with 4GB.
For instance, why swap?  Why not start re-inventing Multics's mapped
files, only really map them?  Why think about files at all - maybe
you should be thinking about data structures with persistence?

Certainly, in the UNIX world, it's nice to have a file represented
by a single-word data pointer, rather than ugly segments of 1-4GB,
and we have 2GB disks on the market now and striped file systems
that span multiple drives - why should we treat disks the way an
8086 treats RAM?  40 bits is only 1 Terabyte - StorageTek makes
tape-beasts that large, and optical jukeboxes are getting close to
that rapidly.  48 bits might be better.

If you've got a machine with, say 10-50 MIPS (a Killer micro or
small Pyramid or Sequent) and 100-1000GB of database, maybe you
could keep the indices in RAM instead of wasting time with disk.
That way, your processors could concentrate on communications or
query-hacking, and not worry about all this disk-space business all
the time.
-- 
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs
# Fax 949-4876.  Sometimes found at Somerset 201-271-4712
# He put on the goggles, waved his data glove, and walked off into cyberspace.
# Wasn't seen again for days.