What matters is the ratio of the size of RAM to the size of active data on the page file AND the nature of the access. Popluating a huge array with i.x where x is much larger that RAM size will page but the thrash won't be too bad because of the sequential nature of the disk access. Totally random access to bytes across an array significantly larger that RAM will thrash to a near standstill and would soon encourage another solution to the problem. On Mon, Dec 8, 2008 at 7:58 PM, Viktor Cerovski <[EMAIL PROTECTED]>wrote:
> > > Matthew Brand-2 wrote: > > > > Hi Eric, > > > > On Mon, Dec 8, 2008 at 2:58 PM, Eric Iverson <[EMAIL PROTECTED]> > > wrote: > >> RAM is not the limit. THE OS makes RAM essentialy invisible to > >> applications. > >> Actively and randomly using an allocation much larger than RAM will > work, > >> but because of swapping between page file space and RAM space > performance > >> will be much slower than if it fit into RAM. > > > > [...] > > > > I am using Ubunto 64-bit as a virtual machine in VMWare Fusion on OSX > > 10.5.5 with 2Gb RAM on a MacBook Pro. > > > Let's guess then that your swap is about 4 Gb large. Try then setting up > swap > to 64Gb and do your calculation with the whole file at once. My guess is > that > your program will be irrecoverably thrashed within a few minutes. RAM still > seems to me to be the limit here. In any case, let me know about results > if you try something along these lines. > > -- > View this message in context: > http://www.nabble.com/Large-mapped-files-and-VAS-again-tp20870863s24193p20906831.html > Sent from the J Programming mailing list archive at Nabble.com. > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
