LEVITT%MIT-OZ@MIT-MC.ARPA (01/03/84)
orking set larger
than real memory, but that's a weak model; along time intervals of
50msec or so (a common worst-case disk seek time), programs reference
far fewer distinct memory locations than they have RAM words. In
fact, a typical cpu at 2Mcycles CAN'T access more than 100Kw during a
typical in that time interval, so "in principle" you should never need
more memory than 100K! (Obviously, I've ignored branching there.)
Today our standards for disk use and storage management are so low
that we can hardly take these calculations seriously; it's easier to
pretend that huge amounts of fast memory are essential than to develop
smart, anticipative memory schemes.
For instance, suppose a Lisa application has 100msec of setup code to
run every time you enter it, which lives in 2K. If Lisa kept that 2K
handy in other applications that can invoke a switch to this one, the
new application can get going instantaneously when the switch is
requested, and the disk can be seeking (and perhaps DMA transferring)
data for the remainder of the setup during that first 100msec. In
other words, there might be NO waiting for the disk even though all
the code for both applications cannot fit. (If there are 10 such
applications you could switch to, there is a 20K overhead, of course.)
This is an obvious idea, but it would be a bitch to implement cleanly
on any software development system I'm aware of, so noone does it.
I think it's the wildest joke that, while so many people seem to be
obsessed with "highly parallel" architectures as a panacea, none of
the wizards at the universities, Apple, or Symbolics has figured out
how to make a CPU and a disk do something useful at the same time.
(With its microtasking, Symbolics' 3600 has at least made a step in
that direction.)
2. Demand paging.
This is simply a technique for the automatic folding or
overlaying of programs (and files if mapped into memory).
It can be a very effective and cheap technique and should
be present so as to free the programmer to deal with
working set management and not physical memory management.
I have already argued that this is often neither "cheap" nor "very
effective". The Xerox PARC groups that did the OOZE and LOOMS storage
management systems achieved mixed results, but they are the only
group I'm aware of with the guts to explore an alternative.
Summary:
One can argue that the current generation of personal computers
(i.e., real memory systems) have the advantage that an
application either fits or doesn't.
Who argued this? Not me. I hope you didn't miss my point.
As we get into more
powerful architectures an application can run correctly but
with severe performance penalties. ...
I guess you mean that a demand-paging virtual memory system is de
facto "more powerful" than a smart, automatic segment-swapping system
you'd rather not try to implement. An anticipatory scheme of this
sort is even MORE powerful than dp-vm, and requires no extra hardware,
only a non-trivial software development environment, some work, and an
open mind.
This is all remiscent of the
earlier debates about whether paging on mainframes would cause
the general level of programming to go down.
Yes, superficially reminiscent. Inherently, timesharing systems
temporarily lowered the value-added of any alternative to demand
paging. Now that personal computers, real-time interactive computer
entertainments, etc. are here, better ideas about improving system
cost/performance are becoming important again. In the device
industries (e.g. watches and videogames), most professionals have
simply descended to assembly language and by-hand storage management.
In the PC world, with its godawful disks, we're witnessing retrofits
of the old timesharing approaches, which barely work. Despite falling
RAM costs, the pressure to develop alternatives will increase.henry@utzoo.UUCP (Henry Spencer) (01/07/84)
"I guess you mean that a demand-paging virtual memory system is de
facto "more powerful" than a smart, automatic segment-swapping system
you'd rather not try to implement. An anticipatory scheme of this
sort is even MORE powerful than dp-vm, and requires no extra hardware,
only a non-trivial software development environment, some work, and an
open mind."
There is only one real problem with anticipatory virtual-memory
schemes. (Note that I am addressing anticipatory-vs-demand issues
*without* attempting to address segments-vs-pages issues.) The only
ones I'm aware of that actually got *implemented* didn't work nearly
as well as demand strategies. I am not up on recent work in this area;
perhaps the millenium has arrived. But the last I heard was a general
conclusion that it is ***NOT*** easy to anticipate the program's demands
well enough to get any large advantage out of it.
(Please do not cite the awesome calculated performance of wonderful
strategy X as a rebuttal; real results on real loads only, please.)
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry