Re: [R] R on dual-core machines

From: Uwe Ligges <ligges_at_statistik.uni-dortmund.de>
Date: Tue 31 Jan 2006 - 00:03:10 EST

Yes, you are right, and you found some relevant posts.

Uwe Ligges

Aleš Žiberna wrote:

> Dear expeRts!
>
> I'm thinking of buying a new computer and am considering dual-core
> processors, such as AMD Athlon64 X2. Since I'm not a computer expert, pleas
> forgive me if some of my questions are silly.
>
> First, am I correct that using a dual-core processor is (for R point of
> view) the same as using a computer with two processors?
>
> If that is true, the posts I found on the list imply that using such a
> processor can usually bring significant improvements (in computational time)
> only if the case where the core (C or sometimes R) is specially designed for
> multiple processors (see comments below).
>
> So based on these and other comments I can conclude that if I'm not prepared
> (able) to make such modifications, I can aspect improvements only in this
> two areas:
> 1. If I am running two instances of R.
> 2. If I'm running several other programs on the computer beside R, the
> programs and R would run faster, since they would not "compete" for
> processor time (so much)

>
> Thanks in advance for any useful suggestions,
> Ales Ziberna
>
> P.S.: Useful posts on the list follow:
>
>
>
> It depends on the usage pattern. If you run multiple CPU-bound processes in
> parallel without too much coordination (parallel make is a good example,
> simulations another), then you get close to double up from a dual. For a
> single R process, you can get something like 40% improvement in large linear
> algebra problems, using a threaded ATLAS.
> For other problems the speedup is basically nil. There is some potential in
> threading R or (much easier) some of its vector operations, but that is not
> even on the drawing board at this stage.
>
> ------------------------------------------------------------------------
>
> If you want to exploit multiple processors, you can write code (e.g., in C)
> called from R (e.g., through .Call or .C) that performs parallel/threaded
> computations in a thread-safe way (e.g., without calling back into R).
> ---
> Another possibility is to replace the BLAS/LAPACK library with a thread-safe
> version. This provides a boost to those R algorithms exploiting these
> libraries.

> ---
> An alternative is to do all of the parallelization within R using nice tools
> like the snow package combined with Rmpi. If your task is computationally
> intensive on the R side, but not on the client, then parallelizing R code
> may be the better way to go. All depends on your application, I think.

>
> ______________________________________________
> R-help@stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html



R-help@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html Received on Tue Jan 31 00:11:48 2006

This archive was generated by hypermail 2.1.8 : Tue 31 Jan 2006 - 02:21:39 EST