🚀 go-pugleaf

In article <1666@ames.UUCP> eugene@ames.UUCP (Eugene Miya) writes:
>His comments in summary: actually, there is more locally in programs
>than most people think.  Peter cites several studies by IBM and others
>on large codes. BUT he believes the important thing, worth a PhD
>thesis, is for someone to go take these scientific codes and rerun them
>on existing CPUs to validate rather than create more hot air.
>Time for critics to stop talking and experiment.
>He also offered to send the text of his American Scientist article on
>VM, but I declined stating the first article should have been enough and
>others can find it in the library.  (Also we want to be careful of
>other copyrights.)

The truth of the claim about program locality depends upon what it
really means.  We have a utility on CTSS (Cray Time Sharing System)
which generates a histogram of the time spent by a program in each n-
word piece of code (most people are familiar with this type of thing).
Based upon runs of this utility, I will agree that most programs spend
more than 90% of their execution time in less than 10% of their code.
If this is what is meant by locality, then your claim is easily shown
true.

We also have a memory simulator on the Cray.  It was built to
determine information about bank conflicts and I/O cycle stealing to
help learn to vectorize code more efficiently.  With this code, we can
see that the 10% of the code that accounts for the time (as above)
also typically accesses about 90% of the data.  In this respect, your
claim of locality is notably false.  This type of memory usage may not
be typical of programs outside the scientific fields that I'm familiar
with, but it is these codes that run on our machines.

Since code only occupies a few hundred thousand words of memory and
data occupies a few million, the locality of reference for the program
as a whole is not significant.

J. Giles
Los Alamos