🚀 go-pugleaf

In article <1991Apr30.163153.18568@midway.uchicago.edu> rtp1@quads.uchicago.edu (raymond thomas pierrehumbert) writes:
 > > Comments on Cyber 205, page faults, etc.
 > 
 >                                      For just about all fluids 
 > codes, we found virtual memory to be essentially worthless.  For
 > out of core codes, we had to manage I/O by hand, and about all
 > virtual memory did for us was to enable us to create blocks of
 > virtual storage that we could move things in and out of "by hand"

True enough.  VM is great for the instruction stream and for small pieces of
data.  It is a bother when you are using large datasets.  (The same holds for
cache.)  But this is not so much an architecture problem as well as an OS/
compiler problem.  You ought to be able to specify what parts of the data
should not be managed through VM (with probably some refinement with respect
to cache management).  Whatever the replacement algorithm is you will always
see some codes (and they are not so uncommon) that trample all over memory in
a way that was not predicted.  As an example: solving a large linear system
that does not fit in memory.  The standard algorithms only lead to page
thrashing.  A colleague of mine once tried a 1000x1000 system on a 1 Mword
205 using standard algorithms.  Result: turn around time approx. 9 hours.
CPU time 3 minutes? (probably less.)  There are algorithms that can do
better, but they need to know the page size and the replacement algorithm.
When applying such an algorithm we got it down to a turn around time of
3 minutes.
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl