Note that currently R internals do not actually use multiple threads
in OpenMP, and there is no documented way to make them do so.
The main issue is that there is insufficient knowlege of where they
are worthwhile (which is both OS and platform-dependent: we don't even
have reliable cross-platform ways to decide a reasonable number of
threads, and the number of virtual cores on a multi-user platform
definitely is not reasonable). Luke Tierney reported that the
crossover point for a speed-up on Mac OS X was much larger matrices
than on Linux, for example, and there is currently no OpenMP support
in the Windows toolchain.
The current implementation is a trial: there are more places planned
to use OpenMP as and when the uncertainties are resolved.
This will change at some point: given the current instability in
thread support in the MinGW-w64 project this may or may not be before
R 2.14.0.
On Wed, 31 Aug 2011, Simon Urbanek wrote:
Pawel,
On Aug 31, 2011, at 4:46 PM, pawelm wrote:
I just found this (performance improvement of the "dist" function when using
openmp):
You failed to describe the platform! See the posting guide (which
asked you to do so 'at a minimum').
.Internal(setMaxNumMathThreads(1)); .Internal(setNumMathThreads(1)); m <-
matrix(rnorm(810000),900,900); system.time(d <- dist(m))
user system elapsed
3.510 0.013 3.524
.Internal(setMaxNumMathThreads(5)); .Internal(setNumMathThreads(5)); m <-
matrix(rnorm(810000),900,900); system.time(d <- dist(m));
user system elapsed
3.536 0.007 1.321
Works great! Just the question stays if it's a good practice to use
"R_num_math_threads" in external packages?
Most definitely not: it is never good practice to use undocumented
non-API variables. See 'Writing R Extensions'.
Normally you don't need to mess with all this and I would recommend
not to do so. The R internals use a different strategy since they
need to cope with the fall-back case, but packages should not worry
about that. The default number of threads is defined by the
OMP_NUM_THREADS environment variable and that is the documented way
in OpenMP, so my recommendation would be to not mess with
num_threads() which is precisely why I did not use it in the example
I gave you.
I'd be cautious there. OMP_NUM_THREADS affects all the OpenMP code in
the R session, and possibly others which use it (some parallel BLAS do
too).
That said, R-devel has new facilities for parallelization so things
may change in the future.
Cheers,
Simon
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
