Re:
> But once a performance plateau is reached, in that every user is
> memory-resident for the duration of his launched processes, and page faults
> are brought down to virtually zero, adding more memory only enriches the
> memory vendor, not you. You're simply spending money for no benefit. Indeed,
...
> Although it is only theoretical on my part, in the sense that I've never
> actually measured the phenomenon, the shape of the performance curve vs.
...
> However, the process very likely even gets worse as you continue to add
...

True.  I've done some tests where a standalone batch application
took 50% *MORE* CPU and elapsed time on a 917 with 576 MB than it
did on the same 917 with 64 MB!  (In all tests, I used the same disk drives,
and the same data layout, and the same software.)
Now, that was a couple of tests out of a dozen...most benefitted somewhat
from the large amount of extra memory.

But, as I've said before, anyone who learns about virtual memory page
replacement techniques (LRU, MRU, random, etc) knows that you can
construct *some* case where adding one more page of real memory will
degrade your performance (because it results in a page that would otherwise
have been left in memory being kicked out).  It may not be very *likely*, but
it is possible.

In addition, and much more of interest to us,:

> large sizes, so must the accompanying memory manager tables. Almost
> certainly, the time to search these tables has to grow (but perhaps only very
> slightly) as excess real memory increases.

I believe the above is the culprit in the tests I ran.
Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *