Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rochester!ur-tut!tuba From: tuba@ur-tut.UUCP (Jon Krueger) Newsgroups: net.arch Subject: Re: Reasons For Large Main Memories Message-ID: <672@ur-tut.UUCP> Date: Wed, 10-Sep-86 17:38:43 EDT Article-I.D.: ur-tut.672 Posted: Wed Sep 10 17:38:43 1986 Date-Received: Wed, 10-Sep-86 21:57:34 EDT References: <1161@bu-cs.bu-cs.BU.EDU> <8529@duke.duke.UUCP> Reply-To: tuba@ur-tut.UUCP (Jon Krueger) Organization: Univ. of Rochester Computing Center Lines: 56 In article <8529@duke.duke.UUCP> rjn@duke.UUCP (R. James Nusbaum) writes: >I have a VLSI CAD system which divides the chip surface into small squares. >The user is viewing these objects on his screen. He can move his view to >any location on the array, he can scroll the screen, he can zoom in or out, >he can change voltage levels at any node in the circuit. > >Now if I can hold all these objects in main memory then the user won't >have to wait for multiple pages to be made resident when he decides >to look at a different part of the circuit. Users, especially non- >technical ones, hate to wait. 1) You have non-technical users who use your VLSI CAD system? 2) You find it unacceptable to wait for objects to page in, but it's acceptable to wait for the entire working set to be made resident every time you run the system or look at a new chip? Seems like the latter will take a lot longer than the former. Now you'll argue, "Sure, but it'll happen less often!" How true. It'll also happen less often that a user will examine an less-recently examined object than a more-recently-examined. In other words, you don't want to make the user wait for some objects more than others. He should be able to perform any operation on any object with good, predictable, response time. It's ok that you may waste memory in keeping resident most objects which are never required. Perhaps your application is small enough and your memory is large enough so you can afford to waste memory. But there will be a cost associated with doing business this way: startup time will be the time required to make the entire chip representation resident, roughly the speed of your disk. You'll pay this price whenever you save changes to your chip, examine a new chip, or quit the application. If you think paging in a few pages is slow, wait until you see how long it takes to completely read in or write out every page, whether needed or not, accessed or not, modified or not. >I will argue no more. I think that if you give me memory for free, I'll >take as much as I can get for a single-user system, up to the limit of >the logical address space. > >Jim Nusbaum If you give me address bits for free, I'll take as much as I can, up to some reasonable limit (2^200 perhaps?), and build environments and applications that make smooth and intelligent tradeoffs between current memory prices, application sizes, and required performance levels, and that automatically move the tradeoffs to reflect changes in memory prices. A virtual memory system with LRU demand paging is the popular solution. I'm sure better ones will emerge. Ever-bigger physical configurations are not a solution. They're a new set of problems... -- jon -- --> Jon Krueger uucp: {seismo, allegra, decvax, cmcl2, topaz, harvard}!rochester!ur-tut!tuba Phone: (716) 275-2811 work, 473-4124 home BITNET: TUBA@UORDBV USMAIL: Taylor Hall, University of Rochester, Rochester NY 14627