Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!spool.mu.edu!uunet!infonode!ingr!ne3005!ne3005!scott From: scott@ne3005.ingr.com (Scott Gentry) Newsgroups: comp.sys.apple2 Subject: Re: The GS Axe is Not Falling Message-ID: Date: 15 Apr 91 13:28:18 GMT References: <51235@apple.Apple.COM> <1991Apr5.224048.29496@kuhub.cc.ukans.edu> <1991Apr6.102920.22598@nntp-server.caltech.edu> <15744@smoke.brl.mil> <13492@ucrmath.ucr.edu> Organization: Intergraph Corp., Reston, VA Lines: 35 rhyde@gibson.ucr.edu (randy hyde) writes: >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 is a blanket statement. Its accuracy depends largely on the size of cache, the application, the compiler, or sometimes the application author. > This may involve one or two memory >fetches depending on the architecture. The performance benefits of MM >*far* outweigh this penalty. You miss the worse case scenario - memory misses. On some computer systems, such as VAX hardware, the flow (simplified), is like this: Cache hit (Everythings fine) Cache miss (Soft page fault) ---> Item found in memory (Yes)---> Get it. ---> Item found in memory (No) ---> (hard page fault) Item found in page file (Yes)---> Get it. Item found in page file (No) ---> Check swapfile, get item. (rest of message deleted) -- ******************************************************************************* * W. Scott Gentry | uucp: uunet!ingr!ne1300!brnded!scott | I didn't * * Intergraph Corporation| America Online: AFL Scott | mean it! * *******************************************************************************