Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!lanl!jlg
From: jlg@lanl.ARPA (Jim Giles)
Newsgroups: net.arch
Subject: Re: VERY LARGE main memories
Message-ID: <7840@lanl.ARPA>
Date: Tue, 23-Sep-86 20:21:34 EDT
Article-I.D.: lanl.7840
Posted: Tue Sep 23 20:21:34 1986
Date-Received: Wed, 24-Sep-86 22:02:07 EDT
References: <1130@bu-cs.bu-cs.BU.EDU> <7144@lanl.ARPA>
Reply-To: jlg@a.UUCP (Jim Giles)
Organization: Los Alamos National Laboratory
Lines: 41
Keywords: VM economy tradeoff

In article <3013@sdcrdcf.UUCP> pmontgom@sdcrdcf.UUCP (Peter Montgomery) writes:
>
>        I once was a system programmer for a CDC 7600 site.  We ran many
>scientific programs, but lacked virtual memory.  Some programs used almost
>all of memory.  These jobs might run faster than the same ones would with
>less memory, but overall system performance suffered.  For example, a
>compilation might not fit in memory alongside a huge scientific job.  If
>the compilation runs alone, the CPU will be idle much of the time it runs.
>Yet the scientific program might have considerable unused code and/or data
>(e.g., the input data for this run does not select Calcomp plots, so those
>routines are never called and their data areas are never referenced;
>another likely possibility is that some dimensions are much larger than
>required).  If either job runs alone, then it wants as much memory as it
>can get.  With virtual memory, the operating system can simultaneously
>load the heavily used parts of BOTH jobs in the machine, for better
>overall performance.

Yes, I agree.  The 7600 probably would have been better off with
virtual memory.  They only had 262 KW of memory (at most - the address
bus was 18 bits, I never saw a 7600 configured with this much).  These
days, 262 KW is only one 64th of the available memory on a 16 MW
machine.  You can afford to load 50-100 KW of unused code into memory,
it's less than one percent(of memory).

The times have changed, the calcomp plotting routines still take up
the same amount of space but the total memory has grown by 100 fold
(soon to be 1000 fold).  The code for the scientific part of the
calculation hasn't changed much either.  The extra memory is being
used by data, not code.  And it is the data in a scientific code that
gets the most use (and the largest part of the data gets the largest
use - the grid, mesh, lattice, particle descriptions, etc.).  It doesn't
trouble me to load unused code, it takes up so little space anyway.

To be sure, there is still a trade-off between throughput and
individual job speed.  I claim that there are types of application in
which this trade-off sould be resolved in favor of job speed.  In this
kind of application, virtual memory in not desireable and is getting
less desireable as machine speed and central memory size increases.

J. Giles
Los Alamos