On 02/08/16 03:10, Ei-ji Nakama wrote:> Hi, > > Create /etc/profile.d/openblas.sh. > Write the following during in this file. > OPENBLAS_NUM_THREADS = 1 > export OPENBLAS_NUM_THREADS > > OPENBLAS_NUM_THREADS environment variable does not affect the OMP_NUM_THREADS. >Thanks for the response. This works fine for R run from the command line (as does setting the same variable in `/etc/environment`), providing a fresh login is made. Unfortunately neither this nor anything else I've tried today appears to set the variable for sessions started through RStudio server (which may or may not be an appropriate issue here). It appears that the rstudio server spawns sessions with a new minimal environment (rstudio::core::system::launchChildProcess) and no option to inject or inherit variables. (Various methods of controlling the session environment are documented in the pro/paid version manual [1], but are not implemented in the public codebase - enterprise features, presumably). Hence approaches like setting the environment in the rstudio-server.service systemd unit, or creating a /etc/pam.d/rstudio service profile including pam_env.so (to load the setting from /etc/environment) don't work. It would probably be possible to work round this by creating a small binary wrapper for the rsession binary which sets the environment, but it would make a mess of the packaging. So I've gone with an `/etc/R/Rprofile.site` containing local({ if (require("RhpcBLASctl", quietly=TRUE)) blas_set_num_threads(1) }) which does mean people get this library loaded in all their sessions but that doesn't seem to cause any particular trouble (yet). Gordon [1]: docs.rstudio.com/ide/server-pro/r-sessions.html> > 2016-08-01 20:06 GMT+09:00 Gordon Ball <gordon at chronitis.net>: >> What is the correct way to globally configure R to default to single (or >> at least, << NUM_CPUS) threaded operation? >> >> >> Using R 3.3.1 (both in debian unstable or using the CRAN repository for >> xenial) with OpenBLAS (0.2.18) defaults to using one thread per >> available CPU, which isn't ideal for machines more than a couple of CPUs. >> >> Setting the environment (OMP_NUM_THREADS or OPENBLAS_NUM_THREADS) in the >> shell works: >> >> $ OMP_NUM_THREADS=1 R >>> Sys.getenv("OMP_NUM_THREADS") >> [1] "1" >>> system.time({x <- replicate(5e3, rnorm(5e3)); tcrossprod(x) }) >> [runs in one thread] >> >> but adding it to /etc/R/Renviron.site doesn't: >> >> $ R >>> Sys.getenv("OMP_NUM_THREADS") >> [1] "1" >>> system.time({x <- replicate(5e3, rnorm(5e3)); tcrossprod(x) }) >> [runs multi-threaded] >> >> (nor does setting the variable at runtime with `Sys.setenv`) >> >> Presumably Renviron is read after the library is already loaded and so >> the environment variable is set too late to matter. >> >> >> >> >> I can think of these solutions, but none of them are ideal: >> >> * remove OpenBLAS (but even single threaded it performs quite a lot >> better than the basic libblas) >> >> * set OMP_NUM_THREADS globally in people's shells with the system >> bashrc (but this doesn't work for non-shell, RStudio server sessions) >> >> * use a library like RhpcBLASctl to set the number of threads in the >> global Rprofile >> >> * compile a custom openblas with threading disabled, or at least a >> small default number of threads >> >> >> Any better ideas? >> >> >> Thanks >> >> Gordon >> >> _______________________________________________ >> R-SIG-Debian mailing list >> R-SIG-Debian at r-project.org >> https://stat.ethz.ch/mailman/listinfo/r-sig-debian > > >
On 3 August 2016 at 16:45, Gordon Ball wrote:
| On 02/08/16 03:10, Ei-ji Nakama wrote:
| > Hi,
| >
| > Create /etc/profile.d/openblas.sh.
| > Write the following during in this file.
| > OPENBLAS_NUM_THREADS = 1
| > export OPENBLAS_NUM_THREADS
| >
| > OPENBLAS_NUM_THREADS environment variable does not affect the
OMP_NUM_THREADS.
Thumbs up to using /etc/profile.d/ -- very nice hook.
| Unfortunately neither this nor anything else I've tried today appears to
| set the variable for sessions started through RStudio server (which may
| or may not be an appropriate issue here).
|
| It appears that the rstudio server spawns sessions with a new minimal
| environment (rstudio::core::system::launchChildProcess) and no option to
| inject or inherit variables. (Various methods of controlling the session
| environment are documented in the pro/paid version manual [1], but are
| not implemented in the public codebase - enterprise features, presumably).
|
| Hence approaches like setting the environment in the
| rstudio-server.service systemd unit, or creating a /etc/pam.d/rstudio
| service profile including pam_env.so (to load the setting from
| /etc/environment) don't work. It would probably be possible to work
| round this by creating a small binary wrapper for the rsession binary
| which sets the environment, but it would make a mess of the packaging.
|
| So I've gone with an `/etc/R/Rprofile.site` containing
|
| local({
| if (require("RhpcBLASctl", quietly=TRUE))
blas_set_num_threads(1)
| })
|
| which does mean people get this library loaded in all their sessions but
| that doesn't seem to cause any particular trouble (yet).
I was just working on something that needed environment variables (for
automating tests to a database backend) and populating
/etc/R/Renviron.site
worked for me. Otherwise explicit code in Rprofile.site is of course good, as
is conditioning. I do that too for some use cases.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
Hi, I was be half asleep in the heat ... 2016-08-04 0:04 GMT+09:00 Dirk Eddelbuettel <edd at debian.org>:> > On 3 August 2016 at 16:45, Gordon Ball wrote: > | On 02/08/16 03:10, Ei-ji Nakama wrote: > | > Hi, > | > > | > Create /etc/profile.d/openblas.sh. > | > Write the following during in this file. > | > OPENBLAS_NUM_THREADS = 1 > | > export OPENBLAS_NUM_THREADS > | > > | > OPENBLAS_NUM_THREADS environment variable does not affect the OMP_NUM_THREADS. > > Thumbs up to using /etc/profile.d/ -- very nice hook. > > | Unfortunately neither this nor anything else I've tried today appears to > | set the variable for sessions started through RStudio server (which may > | or may not be an appropriate issue here). > | > | It appears that the rstudio server spawns sessions with a new minimal > | environment (rstudio::core::system::launchChildProcess) and no option to > | inject or inherit variables. (Various methods of controlling the session > | environment are documented in the pro/paid version manual [1], but are > | not implemented in the public codebase - enterprise features, presumably). > | > | Hence approaches like setting the environment in the > | rstudio-server.service systemd unit, or creating a /etc/pam.d/rstudio > | service profile including pam_env.so (to load the setting from > | /etc/environment) don't work. It would probably be possible to work > | round this by creating a small binary wrapper for the rsession binary > | which sets the environment, but it would make a mess of the packaging. > | > | So I've gone with an `/etc/R/Rprofile.site` containing > | > | local({ > | if (require("RhpcBLASctl", quietly=TRUE)) blas_set_num_threads(1) > | }) > | > | which does mean people get this library loaded in all their sessions but > | that doesn't seem to cause any particular trouble (yet).In this case, hook of the / etc / R / Rprofile.site would be best local({ if(require("RhpcBLASctl", quietly=TRUE)){ if(Sys.getenv("OPENBLAS_NUM_THREADS")=="" & Sys.getenv("OMP_NUM_THREADS")=="") blas_set_num_threads(1) } }) $ OMP_NUM_THREADS=4 R -q -e 'library(RhpcBLASctl);blas_get_num_procs()'> library(RhpcBLASctl);blas_get_num_procs()[1] 4 maybe confusion would be minimal.> I was just working on something that needed environment variables (for > automating tests to a database backend) and populating > > /etc/R/Renviron.site > > worked for me. Otherwise explicit code in Rprofile.site is of course good, as > is conditioning. I do that too for some use cases.I often forget to have set it...orz> Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org-- Best Regards, -- Eiji NAKAMA <nakama (a) ki.rim.or.jp> "\u4e2d\u9593\u6804\u6cbb" <nakama (a) ki.rim.or.jp>