Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!amelia!orville.nas.nasa.gov!fouts
From: fouts@orville.nas.nasa.gov (Marty Fouts)
Newsgroups: comp.arch
Subject: Cray 2 has 2GW address
Message-ID: <235@amelia.nas.nasa.gov>
Date: 24 Feb 88 04:00:58 GMT
References: <9495@steinmetz.steinmetz.UUCP> <3815@megaron.arizona.edu> <15781@beta.UUCP> <9653@steinmetz.steinmetz.UUCP>
Sender: news@amelia.nas.nasa.gov
Reply-To: fouts@orville.nas.nasa.gov (Marty Fouts)
Lines: 35

In article <9653@steinmetz.steinmetz.UUCP> davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr) writes:

>While there are always problems which could be solved to another
>significant digit with more power, even on the Cray2, which can have up
>to 2GB of memory, few problems larger than 500MB are run because the CPU
>takes a lot of real time to clear/search/etc it. Until faster CPUs are
>common, I doubt that there will be a switch to much larger (ie. 64 bit)
>address space, because of market pressures.
>

You appear to be onfusing two different limits on the Cray 2.  The
address space is 2^32 words, which are 64 bits.  The Cray 2 can
address 2GW = 16GB of memory.  The 2GB limit on the current
implementation is the number of 256kbit parts that can fit into the
form factor.  Given 8 times the memory density, (at the same power
consumption, etc) it would be possible to build a 16GB machine. . .

Actually on the each of the two Cray 2s at NASA Ames, there is
typically 1 problem running which occupies between 1/3 and 1/2 of
memory, (2/3 to 1 GB,) and several more problems in the 10 to 80 GB
range, in addition to the interactive unix load of 100+ processes of
~1MB in length.  (and the machines don't *ever* swap)

Having a large memory is advantageous even if a single problem can't
occupy all of it.  The work load we run every day would cause most
supercomputers to spend much of their time doing memory management.

By keeping around 20 active jobs, we can still give good interactive
response, and "batch" throughput an order of magnitude better than
most mainframes.  You haven't lived until you've run on a machine
where GNU emacs is considered a small process. ;-)

One of the ways having a lot of memory helps with slow processor
machines is in the space/time tradeoff.  It is possible for an
application to compute all of the sin/cos values it is going to need
and stuff them away in a table, and then do table lookup, for example.