Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!pacbell.com!ucsd!ucrmath!gibson!rhyde
From: rhyde@gibson.ucr.edu (randy hyde)
Newsgroups: comp.sys.apple2
Subject: Re: The GS Axe is Not Falling
Message-ID: <13492@ucrmath.ucr.edu>
Date: 10 Apr 91 17:33:44 GMT
References: <51235@apple.Apple.COM> <1991Apr5.224048.29496@kuhub.cc.ukans.edu> <1991Apr6.102920.22598@nntp-server.caltech.edu> <15744@smoke.brl.mil>
Sender: news@ucrmath.ucr.edu
Reply-To: rhyde@gibson.ucr.edu (randy hyde)
Lines: 23

re: virtual memory costing cycles

Technically, this isn't correct at all.  I assume the original poster
was referring to memory management hardware, not VM.  Older MMUs (those
not built
onto the CPU) did extract a one-clock-cycle-per-access penalty (this is not
an instruction cycle), however, the latest CPUs have removed this 
penalty.  Now the only penalty incurred happens when there is a cache
miss (only about 5-20% of the time).  This may involve one or two memory
fetches depending on the architecture.  The performance benefits of MM
*far* outweigh this penalty.
As to virtual memory management, only overloaded systems (too many
processes running at once) suffer performance-wise due to VM.  In fact,
well-written and well-designed programs actually run *faster* under a
well-designed VM system than on a bare machine.  For example, a good
part of most programs handles error recovery and obscure portions of the
user interface (a good candidate to write in a HLL, even I must admit)
which rarely, if ever execute.  Under a non-VM system, you have to load
the code and data associated  with this portion of the program from disk
every time you run the program.  On a demand-based VM system you only
load the code and data you actually need.  For many types of programs
(e.g., filters) you would save more time by not loading this extra code
than you would lose because of VM overhead.