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: paging and loading
Message-ID: <7597@lanl.ARPA>
Date: Wed, 17-Sep-86 16:30:58 EDT
Article-I.D.: lanl.7597
Posted: Wed Sep 17 16:30:58 1986
Date-Received: Fri, 19-Sep-86 22:12:14 EDT
References: <832@hou2b.UUCP>
Reply-To: jlg@a.UUCP (Jim Giles)
Organization: Los Alamos National Laboratory
Lines: 29

In article <832@hou2b.UUCP> dwc@hou2b.UUCP (D.CHEN) writes:
>...
>another analogy (and one that i've been using) is this:  imagine
>that you have to xerox ten sets of notes and each set consists of
>ten pages.  if there is a large setup time on the machine, you would
>like to copy the 100 pages in one shot.  even without a large setup
>time, if there are other people on line, you would probably want to
>copy all of your work in one shot instead of getting on the end of
>the line every 10 pages.
>...

This is a remarkably good analogy!  It gives exactly the flavor of
computing on modern supercomputers.  Working with the Cray, for example,
is like having a xerox machine that can duplicate 1000 pages a second
but takes 1000 seconds to get to - even when no one else is in line for
it.  You clearly don't want to divide your 100 page xerography task
into 10 page chunks on such a machine.  You also don't want to force
Cray users to dribble their code into the machine in tiny amounts
for the same reason.

Note that the computational speed of the Cray really does exceed I/O speed
by about a factor of 10^6 - page faults in this kind of environment are
EXTREMELY costly.  If you did page the memory on such a system, it would be
disireable to make the pages large.  That way you can take advantage of the
fact that most I/O comes from consecutive disk locations - therefore there
are fewer seeks with large page size.

J. Giles
Los Alamos