[R] Multithreading

[Luke Tierney]

On Tue, Apr 16, 2002 at 12:10:43PM +0200, Peter Dalgaard BSA wrote:
> Lennart.Araskoug at astrazeneca.com writes:
> 
> > Hi !
> > 
> > I wonder if the R application is capable of utilizing more than one CPU. I
> > need to know since we run it on a SunFire 3800 with 8 750 USIII cpu:s and on
> > a E420R with 4 USII cpu:s and we don't feel like we get the performance we
> > could expect.
> > 
> > I've seen some old discussions claiming that it isn't.
> 
> It isn't ... yet. Duncan and Luke hope to get it going for 1.6.0.
> 
> You can in principle link against a threaded ATLAS library (although
> there are known signal handling problems with that) and get multi-CPU
> numerics performance. And of course run multiple instances of R.
> 

A bit more detail, from my perspective at least:

By 1.6 we hope to have the signal issue sorted out so that threaded
ATLAS can be used safely.  We may also have some early experiments at
parallelizing vectorized arithmetic going by then, but this is likely
to still be very rough at that point.  These are mechanisms that will
allow some degree of implicit parallelism in R; no explicit user
action will be needed to use this (except for the process of enabling
and setting this up, which is likely to be somewhat involved for a
while).

For explicit parallelism the rpvm package is already available, and a
couple of additional simpler (but less powerful) higher level
distributed memory tools are likely to be available by then as
packages. These are essentially ways of organizing and managing the
use of multiple R instances.

Concurrent threads within a single R process is something Duncan and I
have been working towards, off and on, for a while.  The main
motivation is to get improved responsiveness in things like embedding
in data bases and to allow conceptually concurrent tasks, like
concurrent user interaction read-eval-print loops and GUI event loops,
to be programmed more naturally--the same sorts of reasons many
applications use multiple threads on single processor systems.  It is,
in my view, highly unlikely that these R level threads will be able to
run in parallel any time soon, if ever.  At least initially it is
almost certain that we will have to use an approach similar to the one
used in Python and have a global lock that makes sure at most one
threads is running in R code at any given time. (There will be context
switching, just as there is among processes on single processor
machines, so these threads will execute concurrently, but no matter
how many processors you have there will be only one thread actively
running at any given time, at least initially.)  Getting to this point
by 1.7 or 1.8 is feasible in principle, if we don't get sidetracked by
other issues, but it's unlikely to happen by 1.6.

luke

-- 
Luke Tierney
University of Minnesota                      Phone:           612-625-7843
School of Statistics                         Fax:             612-624-8868
313 Ford Hall, 224 Church St. S.E.           email:      luke at stat.umn.edu
Minneapolis, MN 55455 USA                    WWW:  http://www.stat.umn.edu
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._