🚀 go-pugleaf

In article <8494@duke.duke.UUCP> rjn@duke.UUCP (R. James Nusbaum) writes:
>
>Some very good reasons for large main memories seem to have been ignored
>in the recent discussion.
>[deleted text about paging; large data structures]
>...  While it is true that
>sophisticated software can overcome some of the paging problems, in many
>cases the cost of more memory is less than the total cost of developing
>this software.  In todays world silicon is often cheaper than programmer time.
>
>Jim Nusbaum
>Duke University CS Dept.
>Durham,  NC

All good and well, Jim, but not the topic of discussion.  By `large' we
mean on the order of Gbytes, not Mbytes, at which point various other
factors in the system design can degrade performance substantially.
With a database of hundreds of Gbytes, the paging problems facing a
hypothetical programmer with one or two Gbytes of RAM can actually be much
worse than those facing a programmer with one or two Mbytes worth.
All it takes is a few zillion page faults, and the time lost in page-
search-and-replacement can easily exceed the time gained by a slightly
reduced number of accesses.

babbling again,

-dave
-- 
David Hsu  (301) 454-1433 || -8798 || -8715	"I know no-thing!" -eneevax
Communications & Signal Processing Laboratory	/ EE Systems Staff
Systems Research Center, Bldg 093		/ Engineering Computer Facility
The University of Maryland   -~-   College Park, MD 20742
ARPA: hsu@eneevax.umd.edu    UUCP: [seismo,allegra,rlgvax]!umcp-cs!eneevax!hsu

"Electro-nuclear carburetion seems fine..."