Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site zuring.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!seismo!mcvax!zuring!dik
From: dik@zuring.UUCP
Newsgroups: net.arch
Subject: Re: Page size and the meaning of life
Message-ID: <250@zuring.UUCP>
Date: Wed, 30-Oct-85 21:44:16 EST
Article-I.D.: zuring.250
Posted: Wed Oct 30 21:44:16 1985
Date-Received: Sun, 3-Nov-85 07:46:02 EST
References: <926@decwrl.UUCP> <931@lll-crg.ARpA> <7459@watdaisy.UUCP> <939@lll-crg.ARpA> <406@unc.unc.UUCP>
Reply-To: dik@zuring.UUCP (Dik T. Winter)
Organization: CWI, Amsterdam
Lines: 68
Apparently-To: rnews@mcvax.LOCAL

> (Eugene D. Brooks III in lll-crg.931)
> I haven't seen a virtual memory system yet that would stand up
> to one of my simulation programs when the program size exceeded
> the physical memory size.
Do you mean program size or data size?  It makes quite a difference.

> (Amos Omondi in unc.406)
> ....................................As to the supercomputer bit, the
> Cyber 205, a supercomputer in every sense of the word, implements
> virtual store and so far its users seem to be quite happy with its
> perfomance. Of course for disc transfers they have a very large
> "super-page" for efficiency ...
Count me out, page size (large pages; see below) is 65536 64bit words.
A page fault takes 0.5 secs real time!

> (Henry Spencer in utzoo.6086)
> Virtual memory has always meant some speed penalty, although clever design
> can minimize it.
Yeah.  But it is not CPU cycles that become a problem but real time.

> (Amos Omondi in unc.405)
> In taking the Cray 2 as an example, one should take historical, philosophical
> , etc. considerations into account. The CDC 6600, CDC 7600, CRAY 1, and
> CRAY 2 do not have virtual memory; and Seymour Cray was largely responsible
> for their designs. Other CDC machines, inculding the Cyber 200 series which
> are the in Cray1-Cray2 perfomance range, have virtual memory as do several
> of the new Japanese supercomputers .
Yes they have; is it a feature or a bug?

Now my contribution to this discussion.
First computers like Cray and CDC 200 series are intended for the
processing of data on a large scale.  Would they benefit from a VM system?
My opinions on this are ambivalent, so to clarify:
1.  For instrucion space VM is very good because there is no need for
    overlays and their large family, so it is for data space if
    data access is well behaved (note however the caveat below).
2.  For general data VM is not good; it is nice for the programmer to
    be able to write his solution as simple as possible, but when we
    look at CP vs IO tradeoffs this simple solution is not the best.

Question is: what is well behaved data access?
Is a matrix multiplication well behaved?
One would think so; but on the CDC Cyber 205-611 (One pipe, 1 Mword (64
bits) of memory) the most simple implementation of a 1024*1024 matrix
multiply would require about 6 minutes of CP time versus 92 days of IO.
If we vectorize it according to the standards the times are boosted
to the incredible 20 seconds CP and 2.5 hours IO.
There are better techniques; these will boost the IO performance to
3 minutes; watch out however with 1023*1023 matrices the IO will drop
back to some 10 hours unless your working set contains half of the
machines real memory; when you will have 3 minutes.
(Note: these times are based on the 8 Mbit/s disk transfer rate found
with 65536 64bit word pages; with the smaller pages of 2048 words
at our site; the transfer rate would drop.)
There are better techniques available; but these imply the explicit
bypassing of the VM system.  (With these the IO is boosted to about
1 minute IO but CP is increased.)
This holds not only for a matrix multiply; but also for other problems
in numerical algebra.

In conclusion:
1.  VM is very good for instrucion space.
2.  VM should not be applied to data space; the programmer should
    do his own IO if the volume of data is large.  Otherwise he
    will optimize CP; ignoring IO.
-- 
dik t. winter, cwi, amsterdam, nederland
UUCP: {seismo|decvax|philabs}!mcvax!dik