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: <7536@lanl.ARPA>
Date: Mon, 15-Sep-86 17:49:58 EDT
Article-I.D.: lanl.7536
Posted: Mon Sep 15 17:49:58 1986
Date-Received: Mon, 15-Sep-86 21:56:22 EDT
References: <1130@bu-cs.bu-cs.BU.EDU> <7144@lanl.ARPA> <7148@lanl.ARPA> <7094@utzoo.UUCP> <7331@lanl.ARPA> <676@ur-tut.UUCP>
Reply-To: jlg@a.UUCP (Jim Giles)
Organization: Los Alamos National Laboratory
Lines: 29
Keywords: VM economy tradeoff

In article <676@ur-tut.UUCP> tuba@ur-tut.UUCP (Jon Krueger) writes:
>...
>1) Doubtless you can show me cases where it's "extremely easy" to predict
>data usage patterns.  Can you show me one where it's easy to predict the
>code usage patterns?  I want VM to free me from overlays, or code space
>management, not file structuring, or data space management.

In this context, it is important to note that code memory is ALWAYS
trivially small compared to data memory for scientific codes.  This is NOT
just conjecture, the memory used by code has been less than a few percent
of the total memory requirement for every scientific program I've ever
seen.  Furthermore, code usage patterns in these programs ARE easy to
determine for the same reason that the data usage patterns are - the
thing is in a large time-loop: it does physics on the grid, then it
rezones (if necessary), then it dumps a graphic description of the
grid (if requested), then it goes back for the next time step...

To be sure, people use overlays to save even the small space required by
code.  But this is fairly trivial - the physics, rezone, and graphics
subroutines are the ones to be overlayed.  And those programs which
can fit in main memory ARE NOT PENALIZED BY THE PRESENCE OF ADDITIONAL
OVERHEAD IN THE MEMORY INTERFACE!!!

There really are applications which don't benefit very much from a VM
system.  This will remain true as long as VM systems add ANY overhead
at all to the memory interface.

J. Giles
Los Alamos