🚀 go-pugleaf

In article <7597@lanl.ARPA> jlg@a.UUCP (Jim Giles) writes:
>
>Note that the computational speed of the Cray really does exceed I/O speed
>by about a factor of 10^6 - page faults in this kind of environment are
>EXTREMELY costly.  If you did page the memory on such a system, it would be
>desireable to make the pages large.  That way you can take advantage of the
>fact that most I/O comes from consecutive disk locations - therefore there
>are fewer seeks with large page size.
>
>J. Giles
>Los Alamos

This is a good point. One should tailor the paging to the machine. However,
simply saying 
  "x is sooo expensive. gosh. Better not do x, because none of the advantages
	of x are attainable"

.. is not a very scientific attitude. It lies in that fuzzy realm of engineering
judgement. Why doesn't someone do a simulation of the Cray on a slower machine 
that DOES have paging, only slow the paging speed to an appropriately
low rate to compare throughput. Run a VAX from floppy disk as paging store! 
Do an experiment! Get some numbers!! (Maybe this is silly, but you get the idea)

Why? Because one's intuition about performance or throughput is usually wrong.
The reasons why are that the systems we are considering are too complex, and
simply looking at paging speed vs cpu speed is far too simple an analysis
to base a large design decision upon.

In fact, more recent news articles from people on this subject seem to imply
that VM may make you lose 10% on memory references, but the job of using
the machine without VM is so horrendous that you lose all the advantages.

People who are saying "the 205 runs programs x, y, and z faster without VM than
with VM" are looking at only one job at a time. This is fine if your 205 does
ONLY 1 thing all day, every day. Most machines run a mix of jobs, however,
and in this much larger context, individual program performance is far less
important than overall throughput. Anyone who was around in the days of
"batch only" knows this argument inside and out. Batch is fine if you want
to maximize individual program performance, but overall turnaround time is 
dreadful, since ALL things sit in the queue, including the 1/2 second
practice runs.

The point? Looking at single-job performance, no matter how large the job, is 
not good enough. It's the old "1 benchmark doesn't tell anything" rule. You
have to look at a large range of programs before making a decision.
This is also true in design. Running experiments are usually a very rude
awakening. Things you thought were significant aren't, and vice versa. 
Therefore, not designing something into a machine because you think it hits
performance may be a lose if you look at only 1 type of performance, and not
the overall perfomance picture.


Chris Shaw    cdshaw@alberta
University of Alberta
Bogus as HELL !