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

Reply via email to