search for: openblas_num_thread

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...

...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 t...

...<< 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&quot...

...ear Martyn, On Fr, Jan 15, 2016 at 4:01 , Martyn Plummer <plummerm at iarc.fr> wrote: > > Alternatively, you may be able to control the maximum number of > threads > by setting and exporting an appropriate environment variable depending > on what backend you are using, e.g. OPENBLAS_NUM_THREADS or > MKL_NUM_THREADS. Thanks a lot. Running export OPENBLAS_NUM_THREADS = 1 in the bash before starting R solves both problems! Cheers, Daniel

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. 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)...

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 session...

Dear all, I run different R versions (3.2.1, 3.2.2 and 3.2.3) on different platforms (Arch, Ubuntu, Debian) with a different number of available cores (24, 4, 24). The following line produces very different behavior on the three machines: for(i in 1:1e6) {n <- 100; M <- matrix(rnorm(n^2), n, n); M %*% M} On the Ubuntu and Arch machine one core is used, but on the Debian machine ALL

...(and hence in particular when using the BLAS > and LAPACK sources that ship with R). No, I wasn't aware of this. Is there a bug report where this is discussed? Johannes > It seems I can avoid these using > OpenBLAS (but then this really only works find for me provided I setenv > OPENBLAS_NUM_THREADS=1). > > -k > > > Dear all, > > Now that the upcoming Debian release "buster" is frozen, I have started > > supplying backports for it. Pending mirror synchronisations, R 3.6.0 is > > now > > available for Debian buster on i386 and amd64 architectur...

Dear all, Now that the upcoming Debian release "buster" is frozen, I have started supplying backports for it. Pending mirror synchronisations, R 3.6.0 is now available for Debian buster on i386 and amd64 architectures. Please refer to https://cran.r-project.org/bin/linux/debian/ for details. At the moment I am not providing binaries for the arm architecture for buster, as the SD

...on of gfortran in unstable/testing... Can you give a small reproducible example? Johannes > > Best > -k > > > Johannes > > > >> It seems I can avoid these using > >> OpenBLAS (but then this really only works find for me provided I setenv > >> OPENBLAS_NUM_THREADS=1). > >> > >> -k > >> > >> > Dear all, > >> > Now that the upcoming Debian release "buster" is frozen, I have started > >> > supplying backports for it. Pending mirror synchronisations, R 3.6.0 is > >> > now &gt...

...ter handle for one such alarm. Without commensurate discussion on r-devel or r-package-devel this may not help much. Dirk | | Best | -k | | > Johannes | | >> It seems I can avoid these using | >> OpenBLAS (but then this really only works find for me provided I setenv | >> OPENBLAS_NUM_THREADS=1). | >> | >> -k | >> | >> > Dear all, | >> > Now that the upcoming Debian release "buster" is frozen, I have started | >> > supplying backports for it. Pending mirror synchronisations, R 3.6.0 is | >> > now | >> > availabl...

...gfortran in testing/unstable, there are problems with the R BLAS/LAPACK API entries using a Fortran interface (and hence in particular when using the BLAS and LAPACK sources that ship with R). It seems I can avoid these using OpenBLAS (but then this really only works find for me provided I setenv OPENBLAS_NUM_THREADS=1). -k > Dear all, > Now that the upcoming Debian release "buster" is frozen, I have started > supplying backports for it. Pending mirror synchronisations, R 3.6.0 is now > available for Debian buster on i386 and amd64 architectures. Please refer to > https://cran....

..."fix" is in sight. It would be great if at least for the gfortran-8 that Debian will release we would get the old behavior back ... Best -k > Johannes >> It seems I can avoid these using >> OpenBLAS (but then this really only works find for me provided I setenv >> OPENBLAS_NUM_THREADS=1). >> >> -k >> >> > Dear all, >> > Now that the upcoming Debian release "buster" is frozen, I have started >> > supplying backports for it. Pending mirror synchronisations, R 3.6.0 is >> > now >> > available for Debian bus...

....debian.org/DebianScience/LinearAlgebraLibraries As far as I know reference blas and lapack are still single threaded. Alternatively, you may be able to control the maximum number of threads by setting and exporting an appropriate environment variable depending on what backend you are using, e.g. OPENBLAS_NUM_THREADS or MKL_NUM_THREADS. Martyn > A similar problem persists with the parallel package and mclapply(): > > library(parallel) > out <- mclapply(1:1e6, function(i) { n <- 100; M <- matrix(rnorm(n^2), > n, n); M %*% M }, mc.cores = 24) > > On Arch and Debian all 24 cores...

Has anyone succeeded in getting a parallel BLAS, such as Goto's BLAS, installed on a machine running Ubuntu 11.10? I currently have the libatlas3gf-base package installed on a machine with an AMD Athlon X4 processor. I tried to install the libopenblas-base and libopenblas-dev packages but there seemed to be a glich related to having both libopenblas and libatlas3gf installed so that when I

...give a small reproducible > example? > Johannes >> >> Best >> -k >> >> > Johannes >> > >> >> It seems I can avoid these using >> >> OpenBLAS (but then this really only works find for me provided I setenv >> >> OPENBLAS_NUM_THREADS=1). >> >> >> >> -k >> >> >> >> > Dear all, >> >> > Now that the upcoming Debian release "buster" is frozen, I have started >> >> > supplying backports for it. Pending mirror synchronisations, R 3.6.0 is &g...

...| > example? | | > Johannes | | >> | >> Best | >> -k | >> | >> > Johannes | >> > | >> >> It seems I can avoid these using | >> >> OpenBLAS (but then this really only works find for me provided I setenv | >> >> OPENBLAS_NUM_THREADS=1). | >> >> | >> >> -k | >> >> | >> >> > Dear all, | >> >> > Now that the upcoming Debian release "buster" is frozen, I have started | >> >> > supplying backports for it. Pending mirror synchronisations, R...

...t; > >> Best > >> -k > >> > >> > Johannes > >> > > >> >> It seems I can avoid these using > >> >> OpenBLAS (but then this really only works find for me provided I > >> >> setenv > >> >> OPENBLAS_NUM_THREADS=1). > >> >> > >> >> -k > >> >> > >> >> > Dear all, > >> >> > Now that the upcoming Debian release "buster" is frozen, I have > >> >> > started > >> >> > supplying backpo...

Thank you for your answer. In facts, 10 threads are asked by armadillo for some LinAlg, which backs to two threads as warned. But I cannot imagine this costs so much time just for that... A deeper analysis of time spent seems to point that a large time was mainly spent on testthat and Rcpp dependencies compilation... But other recent packages depending on these also are not spending so much time.