Path: utzoo!attcan!uunet!husc6!cmcl2!beta!jlg From: jlg@beta.UUCP (Jim Giles) Newsgroups: comp.arch Subject: Re: VM needed for rapid startup Summary: Paging WITHOUT VM Message-ID: <19730@beta.UUCP> Date: 1 Jun 88 18:16:18 GMT References: <5135@nsc.nsc.com> <4257@killer.UUCP> Organization: Los Alamos Natl Lab, Los Alamos, N.M. Lines: 33 In article <4257@killer.UUCP>, elg@killer.UUCP (Eric Green) writes: > in article <5135@nsc.nsc.com>, stevew@nsc.nsc.com (Steve Wilson) says: > > In article <19496@beta.UUCP> jlg@beta.UUCP (Jim Giles) writes: > >>This problem is an example of the original statement I made on this subject: > >>when the ratio of CPU speed to disk speed is high, virtual memory is not > >>as attractive. The problem is not solved by such schemes as having larger > > Au contraire, virtual memory is not the villain you make it out to be. If you > don't have VM, then your memory must be big enough to hold all of the program > and data. If your memory is big enough to hold all program and data, plus you > have VM, then, once the program is loaded into memory, there will be none of > the "thrashing" that you so decry.... it takes little more time to page-fault > a program into memory than it takes to load it straight into RAM, especially > with today's faster CPU's. > Au contraire yourself! Memory needn't be big enough for the whole program and data in order to benefit from eliminating VM. There are whole classes of programs that know AHEAD OF TIME what data they are going to need next. Such programs can start the I/O to read in pages of data ASYNCHRONOUSLY (so the data will already be in memory by the time the code is ready to use it). For these codes, VM is not a direct hindrance - but the time spend by the hardware doing page table look-ups or whatever is wasted. Before you say this class of programs is hypothetical or too small to care about, I should point out that most CPU cycles in this laboratory are spent running just this kind of program. Scientfic simulation codes very commonly run in the manner above. Furthermore, many of these codes could be modified in minutes to run problems too big for any machine currently made (or proposed). Such programs as these will always run more efficiently on machines WITHOUT VM. J. Giles Los Alamos