🚀 go-pugleaf

In article <2993@h.cc.purdue.edu> aeh@h.cc.purdue.edu.UUCP (Dale Talcott) writes:
>...
>1) Whatever programming technique you use on a Cray to fit ten pounds
>of data into 5 pounds of real memory will also work on the 205.  That
>is, if your program can be run on a Cray with X Mwords of memory, it
>will run on a 205 with X Mwords of memory WITHOUT FAULTING.
>
>2) Monitor mode on the 205 disables external interrupts, so I seriously
>doubt that any sites are running their 205's "with virtual memory
>disabled".
>
Since the trip through the Associative registers costs a machine cycle on
the 205, that means that every memory reference is delayed by at least that
ammount.  (Actually, I suspect that the cost may be higher in that the
selection of the clock rate may have been partially driven by this memory
interface.)  Most memory references are, of course, overlapped by other
computation - so you might think that the extra clock may be negligable.
Unfortunately, as we all found out, a sizable part of execution time in
a 'real' application is inherently scaler.  And for this code, an extra
clock in the memory interface usually means an extra clock over-all.  This
may be part of the explanation of the fact that Crays seem to outperform
Cybers even when small benchmarks indicate the opposite should be true.
(The other reason is the MUCH longer setup time for vector operations
on the Cyber, which can only be offset if the vector sizes are very long
on average.  The distribution of vector lengths within a computation is
not that simple, but it seems that there tend to be a lot of short vectors
in 'real' codes.)

I suspect that the main saving on the Cyber of going into monitor mode is
to prevent parts of your data from being swapped out when you don't want
it to be.  This prevents a page fault later.  As I said before, most of
the programmers I know who have run codes on Cybers prefer to have the
virtual memory off.