From: abuhr@owlnet.rice.edu (Aaron M. Buhr)
Subject: Re: To VM or not to VM?
Organization: Rice University
Date: Thu, 7 Jan 1993 07:17:25 GMT

In article <1ig52uINNbt3@uwm.edu> bloc1469@ee.ee.uwm.edu (Gregory R Block) writes:
>In article <C0GnEI.Ftw@rice.edu> abuhr@owlnet.rice.edu (Aaron M. Buhr) writes:
>>     My system can't find "ee.ee.uwm.edu", or I would have sent this via
>>email.  Since I am not an Amigaphile, nor do I own an Amiga, I don't
>>have any idea what GigaMem is.  Would you mind describing it for me?
>
>GigaMem is a package which gives you Virtual Memory on a per-task
>basis.  It's known to work well.  It's commercial.  (shrug) How much
>can one say about VM?


     I had the impression from previous articles you had posted that you
would prefer no VM whatsoever to having VM.  I would assert that GigaMem is
indeed VM, and according to your previous statements ("VM has no place in a
real-time operating system") that any system using GigaMem would no longer
be a real-time system.  Would you then agree that in some cases virtual
memory is a more useful system function than real-time response (such as my
previous example), given that (according to you) the two are mutually
exclusive?  Would you also be willing to grant then that for many people,
virtual memory would be useful more often than real-time response?

     I submit my previous example as a case in which I would have gained no
practical performance advantage, and certainly no productivity advantage,
from having faster response from my telecommunications program.  If I had
real-time performance in the telecomm package but was not able to decompress
images in the background, I would have realized a performance penalty and
a productivity penalty (performance measured in seconds to both job 
completions, in that I would have had to have run them sequentially, rather
than the decompression using processor cycles unused by the telecomm
program).

     For me, at least, the gains realized in such examples far outweigh
any performance or productivity gains I would realize by having a window
open 1/2 second faster, or by having an unused program become active
2 seconds faster.  VM is consistently more useful and more productive
for me than real-time response.  Given that (as far as I can tell from
your arguments) VM and real-time response are mutually exclusive, I'll
take VM.

     In cases where VM is not necessary, performance should be approximately
the same whether VM is available or not.  In cases where VM is necessary, it
doesn't seem to me that the user will necessarily be able to predict memory
usage patterns (as he would have to under GigaMem, i.e. "do I lock 600K for
program A and give the rest to program B for swapping, or should I lock 400K
for program A give that extra 200K to program B for swapping?") better than
an automatic swapper.  For those that know memory usage patterns for their
programs well enough, user-definable VM would be best.  However, I would
contend that those cases are the exception, and that for most people an
automatic swapper would predict memory usage better than they could.  Thus,
in most cases the automatic swapper would be a superior solution to the
problem.


Aaron Buhr
abuhr@owlnet.rice.edu
Newsgroups: comp.sys.amiga.advocacy