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.gra...@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@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@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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
