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: <7539@lanl.ARPA>
Date: Mon, 15-Sep-86 18:22:27 EDT
Article-I.D.: lanl.7539
Posted: Mon Sep 15 18:22:27 1986
Date-Received: Mon, 15-Sep-86 21:58:38 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: 26
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.

Another thing to remember here is that most of the large scale scientific
codes that run on large memory supercomputers have existed for many
years.  As a result, the usage patterns (both of data and code) are well
known.  These already contain sophisticated memory management routines
that are taylored for the specific code.  When moving to a new and larger
machine, these usage patterns don't change - just the scale of the
memory involved.  The main problems in porting these codes to a new
machine tend to be numerical (different arithmetic on the new hardware),
or incompatibilities in the language (the compiler on the new machine
recognizes a different set of Fortran extensions).

The result of all this is that the people who do large scale scientific
computing have already resolved the memory management problems.  A VM
system would not save them any time, on the contrary - it would require
additional work in trying to rearrange code and data usage patterns to
minimize page faulting.

J. Giles
Los Alamos