Skip to content

Multi-threads in R

6 messages · Gary Dong, michael.weylandt at gmail.com (R. Michael Weylandt, Uwe Ligges +2 more

Take a look at the parallel package which ships with all current versions of R. 

Michael
On Jun 17, 2012, at 11:39 AM, Gary Dong <pdxgary163 at gmail.com> wrote:

            
#
On 17.06.2012 19:04, R. Michael Weylandt <michael.weylandt at gmail.com> wrote:
which is the right answer for the body of the message. For the subject 
line: Take a look at multi-threaded BLAS which can be used with R.

Uwe Ligges
#
I would argue (somewhat emphatically) that the parallel facilities you
are looking at are absolutely not for `for` loops. `for` loops are a
control structure native to imperative programming and, as such, are
inherently stateful. This provides many advantages, but easy
parallelization is absolutely not one of them. Rather consider R as a
functional language and the appropriate "control structure" is the
Map(), most famously of MapReduce, but also inherent in R's *apply()
family of functions. The careful reader will note that here is where
parallelization is exposed. By being state-free, there's no inherent
sequentiality and, consequently, no barriers to parallel computing.

For a somewhat concrete example consider what it would take to do a
state-dependent simulation (like a gibbs sampler) in parallel: it is,
to my mind, quite non-trivial. Compare this to the question of doing
column sums of a matrix in parallel -- effectively trivial. The
parallelization afforded by R is of that second sort.

A red herring in this discussion is the foreach() formalism, but a
moment's thought suggests to me that foreach() is much closer to Map()
than to for().

Best,
Michael
On Sun, Jun 17, 2012 at 1:23 PM, Gary Dong <pdxgary163 at gmail.com> wrote:
#
I think multicore is one of answer if you can write your function in to lapply.

On Mon, Jun 18, 2012 at 12:14 PM, R. Michael Weylandt
<michael.weylandt at gmail.com> wrote: