🚀 go-pugleaf

I don't claim to know where the cost-benefit curve lies,
but there clearly are a lot of problems whose solutions
naturally involve huge address spaces:  databases, number
crunching on huge arrays, image analysis, many kinds of
things that fall into connectionist models, etc.  For
problems like that, solutions on systems with less memory
than the address space of the problem will involve some
kind of mapping between secondary memory and physical
memory.  That means they go slow.  If memory is "cheap
enough" it is obviously preferable to have that memory
be physical memory.  The definition of "cheap enough"
depends on the importance of the problem, the time
pressure on its solution, and your budget.  Saying that
there is a constant that defines the maximum useful amount
of memory is simply stating your interpretation of those
governing factors.

The original note limited the question to single-user
systems.  Even in that context, though, there is an obvious
answer to the complaint that you can't access memory that fast:
get more processors and share the memory among them.  N years in
the future, when processors are available in 1M-processor chips
(that is, one chip=1 million processors), it will seem pretty
silly to be talking about whether a T of memory is too much, just
as now it's pretty silly to be talking about whether a G is
too much.

There's a simple law governing all of computing [don't ping me on
the obvious caveats and quibbles, this is the kind of law that's
supposed to be over-broad but simple]:

There can't be too much memory and no processor is too fast.

-- 
scott preece
gould/csd - urbana
uucp:	ihnp4!uiucdcs!ccvaxa!preece
arpa:	preece@gswd-vms