Skip to content

R 2.14.1 memory management under Windows

5 messages · Spencer Graves, Joshua Wiley, Peter Meilstrup +1 more

#
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
#
On Wed, Mar 21, 2012 at 10:14 PM, Spencer Graves
<spencer.graves at prodsyse.com> wrote:
This seems like it may be an issue with paging, which Windows has
traditionally not excelled at.  That said, on Windows 7 x64 with 6GB
RAM and another 6GB paging file with R version 2.14.1 (2011-12-22), I
get:
Error: cannot allocate vector of size 3.4 Gb
Timing stopped at: 0.01 0 0.01


Cheers,

Josh

so the timing is comparable to nix.

  
    
#
On 22/03/2012 06:11, Peter Meilstrup wrote:
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.

  
    
#
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: