Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ames!sun-barr!newstop!texsun!texbell!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.arch Subject: Re: Architectural Requirements for Unix (was: upgrades) Message-ID: Date: 31 May 90 18:46:48 GMT References: <29972@cup.portal.com> <1990May14.141148.9884@xavax.com> <7754@crdgw1.crd.ge.com> <30016@cup.portal.com> <1990May19.230618.16090@utzoo.uucp> <383@garth.UUCP> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 48 In article <383@garth.UUCP> fouts@bozeman.ingr.com (Martin Fouts) writes: > 3) Smaller is "better". If I have to solve a 1000^3 grid, I have to > solve it. I've done it with segmented memory in the small (Y/MP) > and segmented memory in the large (Cray 2) and virtual memory > (ETA/10.) For my purposes, the Cray 2 was best. Your milage would > vary. In turn, you're making a false assumption: that there's something inherent in these very large programs (VLPs) that people are complaining about that requires them to be large. Nobody is denying that some problems require big iron. Text processing, text editing, window systems, and so on... the majority of VLPs that come under fire... have no inherent reason to be very large. Even machines as small as a 128K Mac can run excellent windowing systems, and editors and text processors are even smaller. > I need paging. I need it to keep the total amount of memory I am > using small and make my programs more efficient by: > 1) Using implicit sharing of text segments This does not require paging. Look at good old PDP-11 UNIX. > 2) Using copy on write sharing of forked images This requires paging. Fork() is a poor match for a non-demand-paged architecture. My reaction is that we don't need fork(). > 3) Using explicit sharing of library code This does not require paging. Look at good old PDP-11 RSX. > 4) Using explicit sharing of multithreaded applications This does not require paging. Look at the Transputer. > 5) Using good locality of reference to minimize resident sets This is the big win for paging systems. You don't need to pull any more reasons out of the hat. However, when you have a small program anyway this becomes much less important. The question shouldn't be "is paging good" or "is paging bad" or "who needs it". The question is "do you need it". Also, paging and bloated programs are not synonymous. People can write bloated program with overlays: look at the OS/360 kernel as described in the Mythical Man-Month. The problem isn't paging. The problem is people who think that because memory is cheap they can act like it's free. -- `-_-' Peter da Silva. +1 713 274 5180. 'U` Have you hugged your wolf today? @FIN Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.