🚀 go-pugleaf

In article <1310@ucbcad.berkeley.edu> faustus@ucbcad.berkeley.edu (Wayne A. Christopher) writes:
:
>
>What we need to ask is, who will need more than ~1G of memory?  I think
>the only applications that currently could use this much memory are
>scientific programs that run on Crays (which I think are addressible to
>the 64-bit word anyway).  I certainly haven't been running into the 1G
>limit too often lately.
>
There could be other applications besides the often mentioned scientific
and graphics programs which could potentially benefit from machines with
larger address spaces.  Consider database applications, for example.
Some sites have hundreds of 3380 disk drives holding databases.  Currently,
there is no way to address more than about one disk worth (3380's 
are 2.5-5.0 GB) in IBM's 32 bit address space.  With a 64 bit address space,
the entire disk farm could be addressed.  All this data need not be 
accessed at one time in order to justify doing this: there are efficiency
improvements in access time which would be expected by using the pager
as the access method.  There may be other applications which would justify
the use of a large address space. 

The proper metric to use is the size of the system secondary storage.  The
virtual address space should be big enough to encompass the size of secondary
storage in a virtual memory world.  I know of one system that allows virtual
memory to be kept on tape as well as disk (obviously the access time is
slower, but the entire memory segment is restored once an access is made;
efficient).  At a minimum, the size of the largest OBJECT should fit in the
address space, and this object may be a database, a process address space for
an engineering, scientific, or graphical program, or other applications.  What
other applications or objects have people encountered that needed more than 
1 GB?

Since today there are deskside servers available for 4 MIPS workstations with
560 MB on a disk, I don't think the day is far off when even "small" systems
may find the 32 bit limit a burden.  I foresee a rosy future for the company
which chooses to start developing its 64 bit systems now in anticipation of 
that future.  



  Hugh LaMaster, m/s 233-9,  UUCP {seismo,topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

"In order to promise genuine progress, the acronym RISC should stand 
for REGULAR (not reduced) instruction set computer." - Wirth

("Any opinions expressed herein are solely the responsibility of the
author and do not represent the opinions of NASA or the U.S. Government")