Paul Gilbert
2012-Sep-17 19:10 UTC
[R] Question about R performance on UNIX/LINUX with, different memory/swap configurations
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