Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!husc6!panda!genrad!decvax!mcnc!duke!rjn
From: rjn@duke.UUCP (R. James Nusbaum)
Newsgroups: net.arch
Subject: Re: Reasons For Large Main Memories
Message-ID: <8529@duke.duke.UUCP>
Date: Sun, 7-Sep-86 22:18:15 EDT
Article-I.D.: duke.8529
Posted: Sun Sep  7 22:18:15 1986
Date-Received: Mon, 8-Sep-86 20:58:05 EDT
References: <1161@bu-cs.bu-cs.BU.EDU>
Reply-To: rjn@duke.UUCP (R. James Nusbaum)
Organization: Duke University, Durham NC
Lines: 96
Summary: a long example and rebuttal

In article <1161@bu-cs.bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
>
>>From: rjn@duke.UUCP (R. James Nusbaum)
>>Your point is also true.  However many Lisp systems are single user systems.
>>Having even a couple of hundred megawords of memory could totally eliminate
	[ omitted to save space]
>>If we had 200Mb of memory then we would have no need for paging at all!  This
>>would significantly speed up many applications.
>
>But you still miss the point. In the first place, move this to GigaBytes,
>obviously adding a few more megabytes is not interesting (so why do people
>keep going back to it?) Even 200MB is quite different than 5X that or
>more.
>Now, ok, you eliminated paging, garbage collection has become a field
>service thing. But, could you do anything useful with all that memory
>and that (relatively) itty-bitty processor? How long would it take you
>to do a MEMQ of a list of a few HUNDRED MILLION lisp objects long?
>etc.  Paging is only an advantage at some interim and relatively low
>point (100-200MB perhaps, probably less.)

Anyone who would have a list 100,000,000 objects long is a a poor Lisp
programmer.  In case you haven't heard Lisp has things called arrays and
yes, I know of many things which I could do with that itty-bitty
processor.  The following is an example:

I have a VLSI CAD system which divides the chip surface into small squares.
Each square can be occupied by a cell (a circuit description).  I would
love to have at least a 512x512 array of these cells.  Note: a cell may
be an empty cell, no circuitry.  That means I need 262,144 locations in
my array, each containing a cell pointer (32 bits).  In a full array
each pointer would point to an object (not a Lisp object, an object-oriented
programming object) which I would like to be large.  The larger the
object the faster it is to do things like repaint the screen because of
less information sharing and pointer chasing.  Let's assume a 1k object.
We're already up to 268,440,000 bytes.  Now add simulation data to the 
objects, now add color to the visual description of the objects, now
add different representations, now add the code to handle these objects.
We are already over 1Gb, I assure you.

Now throw in the monkey wrench which would kill any smart paging scheme of
a virtual memory system.  It's called the user.  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.

I'm not saying that an application like this cannot be done in much
less memory, it has been.  But even on a Symbolics (pretty much
the fastest widely available Lisp machine) it is slow, slow, SLOW.

>Now, I could see a lisp-machine type saying that only garbage
>collecting on Xmas day would be a big win, if they could actually
>accomplish that, and would otherwise run 'reasonable' programs.
>Somehow though I suspect it won't work that way. More like the machine
>down every Sunday for garbage collection (though I suppose many
>long-running applications could be checkpointed to disk and a simple
>re-boot would suffice.)

This is pretty much exactly what happens.  To my knowledge the Symbolics
at a certain university (not the one I'm at now) has never had to
garbage collect during a run session.  When a session is over the world
is saved and a garbage collection is run.  This is really a function
of a large virtual memory space, and has nothing much to do with
physical memory space.  

It certainly would take a long time to garbage collect 1-4Gb. Fortunately
there are things like incremental garbage collection, parallel garbage
collection, and garbage collection hardware to help out.  All I've ever 
said is that a global garbage collection would be much faster if the whole 
world were resident in physical memory.

>Ok, but still obviously not cost-effective (the magic ingredient that
>gets thrown out whenever this topic starts getting discussed, 1GB of
>memory is going to cost you around $1M [there's more than chips
>involved, don't just tell me the 1MB price * 1,000, you'll need
>backplane, power-supplies etc etc, if your figures come to $500K,
>fine, same thing], how many of us would buy a lisp-machine to run one
>application for $500-$1M? $250K?)
>
>	-Barry Shein, Boston University

If you're going to use todays cost figures the whole discussion, which
originally asked about large physical memories for minicomputers, becomes
a little ridiculous.  I certainly expect memory prices to keep going
down until the physical limits of chip manufacturing are reached.  I
think we are still a good ways away from that wall.

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