Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!hc!beta!jlg
From: jlg@beta.UUCP (Jim Giles)
Newsgroups: comp.arch
Subject: Re: VM needed for rapid startup
Summary: disk speed vs. cpu speed
Keywords: paging virtual-memory speed
Message-ID: <19322@beta.UUCP>
Date: 25 May 88 17:55:29 GMT
References: <463@cvaxa.sussex.ac.uk>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 22

In article <463@cvaxa.sussex.ac.uk>, aarons@cvaxa.sussex.ac.uk (Aaron Sloman) writes:
> [...]
> Anyhow, while disk access remains significantly slower than main memory,
> something like paged virtual memory will remain highly desirable for
> those of us who want to use large sophisticated software packages like
> AI development environments, powerful editors, etc. EVEN if there is
> enough physical memory for the whole package.

One of the things that makes virtual memory LESS useful than it used to be
is the fact that disk is so slow compared to main memory (and CPU speed).
If it takes less than the disk access time for your program to execute
through a whole page of code, a busy multiprocessing environment may spend
nearly all its time waiting on page faults. What's really needed is some
form of mass storage that is faster than disk - implement a paging scheme
off the intermediate storage (which in turn can page off disk in larger
chunks?).

In any case, fast startup is a minor convenience.  The important thing is
response time while running and turnaround for compute intensive jobs.
To an extent, both of these requirements are incompatible with paging
if the disk is VERY much slower than the CPU.  There are no easy answers
here.