Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!hc!beta!jlg
From: jlg@beta.UUCP (Jim Giles)
Newsgroups: comp.arch
Subject: Re: VM needed for rapid startup
Message-ID: <20128@beta.UUCP>
Date: 9 Jun 88 20:09:36 GMT
References: <19730@beta.UUCP> <4332@killer.UUCP> <802@elxsi.UUCP> <10078@ames.arc.nasa.gov>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 47

In article <10078@ames.arc.nasa.gov>, lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
> [...]
> These advantages to memory management, well established for at least the
> last 15 years, come at the penalty of expensive, power consumptive, space
> consumptive associative registers.  But not, in a properly designed system
> (most systems I have seen have been properly designed), does it cause a
> slowdown in memory access or, as has been implied several times, some sort
> of other mysterious inefficiency.

If this is the case, then I have never seen a 'properly designed' system.
Overhead in the memory management hardware has been present in every VM
system I've ever used. This includes the CDC vector machines.  From what
I've been able to find out form the hardware people, the Cyber VM accounts
for a one clock delay in the speed of scalar memory references vs. what
could have been achieved without the VM.  To be sure, you can turn the VM
off, but this doesn't speed the memory references since the memory mapping
is still done (the identity transformation).

> I claim, based on my experience, that,
> other things being equal (e.g. clock speed of CPU), a memory mapped system
> will always be "faster" than a non-memory-mapped system.

Interestingly, I agree with this statement entirely.  The problem is
that 'other things' are seldom 'equal'.  The thing that is most unequal
between environments is the job-mix.  Now, the job mix of most (even
scientific) programming environments would probably benefit from VM in
terms of throughput.  But, if total throughput is a secondary
consideration and turnaround of single production codes is paramount,
then VM is probably a net loss - you would rather have the hardware
spent on another vector multiply unit or something.

The issue that NO ONE has yet responded to is this: a code which has
predictable data usage patterns can pre-read (and post-write) data
asynchronously - sometimes the code can run to completion without ever
waiting for I/O to complete.  No VM system I've ever seen can do this.
And (in spite of suggestions) there is NO commercial machine presently
available which even takes 'hints' about the data usage patterns.  Even
if such a machine DID exist, the best it could do is tie the speed of
the non-VM code which does it's own asynchronous paging.

To be sure, VM is great at increasing the throughput of multiprocessing
systems with large numbers of users or independent jobs running at once.
VM does nothing to help the turnaround of individual jobs in such a
system (much less in a dedicated system in which turnaround is THE major
criterion).

J. Giles
Los Alamos