[Rd] R 2.14.1 memory management under Windows

[Spencer Graves]

Thanks for the replies and please excuse my failure to provide 
sessionInfo():


WINDOWS 7 WITH 8 GB RAM:


 > sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: x86_64-pc-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] splines   stats     graphics  grDevices utils     datasets  methods
[8] base

other attached packages:
[1] fda_2.2.8 zoo_1.7-7

loaded via a namespace (and not attached):
[1] grid_2.14.1    lattice_0.20-0


FEDORA 13 LINUX WITH 4 GB RAM (copied manually, thereby increasing the 
risks of copying errors):


 > sessionInfo()
R version 2.12.0 (2010-10-15)
Platform:  i386-redhat-linux-gnu (32-bit)

locale:
  [1] LC_CTYPE=en_US.utf8        LC_NUMERIC=C
  [3] LC_TIME=en_US.utf8        LC_COLLATE=en_US.utf8
  [5] LC_MONETARY=C            LC_MESSAGES=en_US.utf8
  [7] LC_PAPER=en_US.utf8    LC_NAME=C
  [9] LC_ADDRESS=C            LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.utf8    LC_IDENTIFICATION=C

attached base packages:
[1] splines  stats  graphics  grDevices  utils  datgasets  methods
[8] base

other attached packages:
[1] fda_2.2.6  zoo_1.6-5

loaded via a namespace (and not attached):
[1] grid_2.12.0  lattice_0.19-30


       Thanks again,
       Spencer


On 3/22/2012 5:02 AM, Prof Brian Ripley wrote:
> On 22/03/2012 06:11, Peter Meilstrup wrote:
>> My guess would be that it's a matter of having swap space be a dedicated
>> partition or fixed-size file (Linux, usually) versus swapping to a 
>> regular
>> file that grows as needed (Windows and OS X, usually.) So if you
>> defragmented your drive and set Windows to have a fixedsize swap 
>> file, it
>> would probably behave more like your Linux machine.
>
> There is far more to the topic than that, but the answer here appears 
> to be a complete failure to supply the relevant information.
>
> We haven't even been told the 'at a minumum' information required by 
> the posting guide, so we do not know what architectures are in use.  
> The messages suggest that 'Linux' is 32-bit and 'Windows' is 64-bit, 
> in which case the tasks are simply not comparable.  On 32-bit R on 
> Windows I got the message about 3.4GB after 0.05 sec.  Conversely, 
> with 64-bit R on an 8GB Linux box with 16GB swap it swapped away for 
> about 10 minutes.  On a 32GB box it succeeded after 270s, typically 
> using 8-14GB.  The object SG tried to create is a bit over 7GB.
>
> But Windows' memory management is notoriously slow, and R actually 
> adds a layer on top to make it tolerable for routine use of R.
>
> I have no idea why this was posted on R-devel: it did not involve R 
> development nor programming, just a basic understanding of 32- vs 
> 64-bit R.
>
>>
>> Peter
>>
>> On Wed, Mar 21, 2012 at 10:14 PM, Spencer Graves<
>> spencer.graves at prodsyse.com>  wrote:
>>
>>> I computed "system.time(diag(30000))" with R 2.12.0 on Fedora 13 Linux
>>> with 4 GB RAM and with R 2.14.1 on Windows 7 with 8 GB RAM:
>>>
>>>
>>> Linux (4 GB RAM):  0, 0.21, 0.21 -- a fifth of a second
>>>
>>>
>>> Windows 7 (8 GB RAM):  11.37 7.47 93.19 -- over 1.5 minutes.  Moreover,
>>> during most of that time, I could not switch windows or get any 
>>> response
>>> from the system.  When I first encountered this, I thought Windows 
>>> was hung
>>> permanently and the only way out was a hard reset and reboot.
>>>
>>>
>>>       On both systems, diag(30000) generated, "Error:  cannot allocate
>>> vector of size ___ Gb", with "___" = 3.4 for Linux with 4 GB RAM and 
>>> 6.7
>>> for Windows with 8 GB RAM.  Linux with half the RAM and an older 
>>> version of
>>> R was done with this in 0.21 seconds.  Windows 7 went into 
>>> suspension for
>>> over 93 seconds -- 1.5 minutes before giving an error message.
>>>
>>>
>>>        I don't know how easy this would be to fix under Windows, but 
>>> I felt
>>> a need to report it.
>>>
>>>
>>>       Best Wishes,
>>>       Spencer
>>>
>>>
>>> -- 
>>> Spencer Graves, PE, PhD
>>> President and Chief Technology Officer
>>> Structure Inspection and Monitoring, Inc.
>>> 751 Emerson Ct.
>>> San José, CA 95126
>>> ph:  408-655-4567
>>> web:  www.structuremonitoring.com
>>>
>>> ______________________________**________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel> 
>>>
>>>
>>
>>     [[alternative HTML version deleted]]
>>
>>
>>
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>


-- 
Spencer Graves, PE, PhD
President and Chief Technology Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph:  408-655-4567
web:  www.structuremonitoring.com