From simon.urbanek at r-project.org  Wed Mar 18 16:32:15 2009
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Wed, 18 Mar 2009 11:32:15 -0400
Subject: [Rd] R thread safe
In-Reply-To: <4f1819890903180711pcdd2bdbuc4eb15f7af8575f4@mail.gmail.com>
References: <49C0F021.8000108@health.sdu.dk>
	<4BD0BA7D-242B-4D27-A346-745AB8AD088E@r-project.org>
	<4f1819890903180711pcdd2bdbuc4eb15f7af8575f4@mail.gmail.com>
Message-ID: <83E1179B-072A-42F1-98FB-A06790DA393D@r-project.org>


On Mar 18, 2009, at 10:11 , Ted Byers wrote:

> On Wed, Mar 18, 2009 at 9:28 AM, Simon Urbanek
> <simon.urbanek at r-project.org> wrote:
>> Things cannot happen if you don't ask ...
>>
>> Cheers,
>> Simon
>>
> Then I have two questions.
>
> 1) What multicore package?  I didn't know there was one, and would  
> be interested in seeing what it does.
>


It's on CRAN, so just look at it for yourself:

http://cran.at.r-project.org/web/packages/multicore/index.html

multicore: Parallel processing of R code on machines with multiple  
cores or CPUs
This package provides a way of running parallel computations in R on  
machines with multiple cores or CPUs. Jobs can share the entire  
initial workspace and it provides methods for results collection.

It's actually referenced in several places of the R website ...


> 2) Has there been any consideration of using Intel's threading  
> building blocks library?

I don't think so, because IMHO it makes no sense - you're missing the  
main point that R is not thread safe. There are ways to use threads  
from within R very cautiously (see Luke's parallelized vector math  
operations for R for example). There are many good methods to use  
threads in general (pthreads, OpenMP, GCD, ...) and you can do that as  
long as you don't use memory allocation in R and don't call any R  
functions that may do that (which is most of them ;)). Making R thread- 
safe is not really an issue of a threading toolkit...

Cheers,
Simon


>  They do have an open source version. It can
> apparently be built on Unix and Windows, and since it is open source,
> you can adapt it to any platform that you need to support if there is
> one that it doesn't presently support. And it allows a programmer to
> work at a higher logical level than if he focussed largely on the
> lower level details of creating and managing threads (for example, one
> can create a 'parrallel for loop' and the library, once properly
> initialized, will handle creating and cleaning up after any new
> threads that may be needed): now that is a freedom in multithreaded
> programming I truly appreciate.  According to the documentation I have
> read, it scales well to larger numbers of processors or cores.  The
> code in it that I have studied is all C++, so if there is much C++
> code in R, it presents an option.  I do know, though, that in my C++
> code where it would provide a benefit (mostly vector and matrix
> algebra), most of it would need to be completely rewritten.  It does
> present a rather different way of thinking about multithreaded
> programming (it reminds me of the sort of thing I did when writing
> code to run on a supercomputer supporting vector algebra decades ago).
> With ITT, if Lapack was rewritten to take advantage of it, much of
> the code would look quite different from what it does today.  Of
> course, if you're already using it, I might as well shut up and go
> away.  ;-)  I am just learning to use it, as I am just learning to use
> R, so I am afraid I can't offer much more info than this, though.
>
> Cheers,
>
> Ted
>
>



[Rd] R thread safe
Simon Urbanek