🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.arch
Article #2792

Re: Reasons For Large Main Memories

#2792
From: Jon Krueger
Date: Wed, 10 Sep 1986 21:38
56 lines
3562 bytes
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 
Technical Details
Message-ID: <672@ur-tut.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!rochester!ur-tut!tuba
References: <1161@bu-cs.bu-cs.BU.EDU> <8529@duke.duke.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!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