Path: utzoo!attcan!uunet!comp.vuw.ac.nz!gpwd!zl2tnm!don From: don@zl2tnm.gp.govt.nz (Don Stokes) Newsgroups: comp.arch Subject: Re: Tradeoffs Message-ID: Date: 10 Jun 90 22:16:02 GMT References: <672@sibyl.eleceng.ua.OZ> Organization: Me? Organised? Lines: 79 ian@sibyl.eleceng.ua.OZ (Ian Dall) writes: > In article <136844@sun.Eng.Sun.COM> martyi@sun.UUCP (Marty Itzkowitz) writes: > } > }The main argument for NOT letting the virtual memory system deal with it > }is that the program has a much better idea of an appropriate strategy > }for page replacement than the OS can infer from past behavior. When the > }user switches to a new file the editor can infer that the pages from the > }previous edit can be discarded, > > It would probably be inferring incorrectly. I very frequently hop back > and forth between a foo.c file and a foo.h file (for example). The > only way emacs could resonably know that you didn't want a buffer > again is if you killed it. I think you (and others) are missing the point. An argument along these lines went through comp.os.vms on the subject of the EDT editor vs the EVE/VAXTPU editor on VMS, myself being one of the major protagonists, along with someone who's idea of a "test" being to get the largest machine available and use it standalone (!) 8-) First a bit of background: EDT is a fairly old text editor, developed on the pdp11 under RSX (I think -- I first met the pdp11 version under RSTS/E). One of its design goals, due to the 16 bit address space, is to allow editing of files larger than available memory by editing a small buffer within a work file; I don't know the exact details. VAXTPU is the VAX Text Processing Utility. EVE is a text editor written in on VAXTPU. I will refer to this as TPU, as it is the TPU part which does the dirty work, similarly, editing with EVE is not the only thing that TPU gets used for. From most users points of view, TPU is a *lot* faster than EDT. The only place where this is never the case is starting up. TPU reads the whole file into virtual memory. A small file (say less than 500K) tends to find its way into core and stay there; searches and editing are *fast*. EDT will tend to kick its buffering strategies into play right from square one; searches tend to be a bit slower, editing within a small area is fast since it is working within its buffer. This is fine, although on a loaded I/O system, the startup time of TPU can be a little annoying (it is a bit slow starting up, even before loading the file), whereas EDT tends to be "there when you want it". Things can change radically when big files get involved, say >20MB. A search through memory results in memory being paged in as the search proceeds, and paged out behind. The next search does exactly the same thing. All this is happenning at the expense of the rest of the memory system, and is especially nasty if a lot of modifications are being made to the file. Worse, the paging is all through the system pagefile(s); as such it comes out of the user's pagefile quota. The pagefile quota is a brick wall which marks the maximum size of a file that can be edited by TPU. (The quota is necessary IMHO -- the alternative to not getting all the virtual memory you want is blowing the page files occasionally -- this is *not* nice.) EDT, on the other hand, works with a reasonably large buffer, pages data in and out of memory in large chunks. Since it uses temporary files, only the file system limits the size of the file being edited. Performance/file size is linear. What I wish would happen is that someone at DEC would realise that trying to use virtual memory entirely is *not* a great idea, and that paging stuff in and out in a semi-intelligent fashion when core runs out really isn't a stupid idea. TPU is supposed to be a Text Processing Utility, not just an editor for composing notes or programs with. Summary: Systems that rely on virtual memory are fine when the are using physical memory. After that, temporary files would remove the pagefile quota brick wall and reduce the impact on the memory system when large files get involved. Memory might be cheap, but it ain't *that* cheap. (Now who was it who said "virtual memory is a way to sell more physical memory"?) Don Stokes, ZL2TNM / / Home: don@zl2tnm.gp.govt.nz Systems Programmer /GP/ Government Printing Office Work: don@gp.govt.nz __________________/ /__Wellington, New Zealand_____or:_PSI%(5301)47000028::DON