[R] Question about R performance on UNIX/LINUX with, different memory/swap configurations

[Paul Gilbert]

On 12-09-17 06:00 AM, r-help-request at r-project.org wrote:
> Date: Sun, 16 Sep 2012 14:41:42 -0500
> From: Dirk Eddelbuettel<edd at debian.org>
> To: "Eberle, Anthony"<aeber at allstate.com>
> Cc:r-help at r-project.org
> Subject: Re: [R] Question about R performance on UNIX/LINUX with
> 	different	memory/swap configurations
> Message-ID:<20566.11126.175103.643079 at max.nulle.part>
> Content-Type: text/plain; charset=us-ascii
>
>
> On 16 September 2012 at 13:30, Eberle, Anthony wrote:
> | Does anyone have any guidance on swap and memory configuration when
> | running R v2.15.1 on UNIX/LINUX?  Through some benchmarking across
> | multiple hardware (UNIX, LINUX, SPARC, x86, Windows, physical, virtual)
> | it "seems" that the smaller memory machines have an advantage.
>
> Would you be able to provide some "empirical proofs" for that conjecture?
> Please demonstrate how, say, a X gb ram machine outperforms one with Y gb
> where Y > X.
>
> Less memory is/never/  better.

Exceptions to the rule:
There are a couple of unusual situations were less memory can be better. 
As someone else pointed out, if you start swapping then performance 
takes a hit. So, if you have enough physical memory to do your own job, 
but not enough to let other jobs run and push you into swapping, then 
you may get better performance on the single job. Second, if you have 
long recursions that grab lots of memory, then these will use swap. 
Typically one would want the job to succeed, and thus swap is good, but 
slow. However, if your code is bad and doing an infinite recursion, then 
with swap this can take a very long time to fail, whereas with only 
physical memory it fails much more quickly.
Third, there were (are?) situations where 32 bit machines/OSes perform 
(very slightly) faster than 64 bit machines/OSes, and since the former 
typically have less memory, one could have the impression that less 
memory is faster.

Paul
>
> Dirk
>
> -- Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com