R foreach not using multiple cores
Asked Answered
P

1

6

I have a case where foreach using doMC as a backend produces different behaviors on different machines.

On a linux server running Ubuntu 12.04.4 LTS the following code (adapted from the foreach vingette) runs 5 jobs simultaneously on a single core, which is not the desired behavior.

library(foreach)
library(doMC)

registerDoMC(cores=5)
getDoParWorkers()

x <- iris[which(iris[,5] != "setosa"), c(1,5)]
trials <- 10000
r <- foreach(icount(trials), .combine=cbind) %dopar% {
  ind <- sample(100, 100, replace=TRUE)
  result1 <- glm(x[ind,2]~x[ind,1], family=binomial(logit))
  coefficients(result1)
}

Session info:

> sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-pc-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C         LC_TIME=C            LC_COLLATE=C         LC_MONETARY=C       
 [6] LC_MESSAGES=C        LC_PAPER=C           LC_NAME=C            LC_ADDRESS=C         LC_TELEPHONE=C      
[11] LC_MEASUREMENT=C     LC_IDENTIFICATION=C 

attached base packages:
[1] parallel  stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] doMC_1.3.3      iterators_1.0.7 foreach_1.4.2  

loaded via a namespace (and not attached):
[1] codetools_0.2-8 compiler_3.1.0  tools_3.1.0

The same code run on a Mac running OSX 10.7.5 produces the desired and expected behavior of running 5 jobs on 5 different cores.

Session info:

> sessionInfo()
R version 3.0.1 (2013-05-16)
Platform: x86_64-apple-darwin10.8.0 (64-bit)

locale:
[1] C

attached base packages:
[1] parallel  stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] doMC_1.3.2      iterators_1.0.6 foreach_1.4.1  

loaded via a namespace (and not attached):
[1] codetools_0.2-8 compiler_3.0.1  tools_3.0.1

I have also observed the same behavior using other parallel backends. Both machines have 20+ cores. Any ideas on what's going on?

Pogy answered 10/6, 2014 at 16:1 Comment(0)
P
6

The issue was caused by OpenBLAS. Switching to ATLAS solved the problem. The recipe for switching between BLAS libraries in Linux is on Nathan VanHoudnos's blog:

Switching between BLAS libraries

Now we can switch between the different BLAS options that are installed:

sudo update-alternatives --config libblas.so.3gf

There are 3 choices for the alternative libblas.so.3gf (providing /usr/lib/libblas.so.3gf).

Selection Path Priority Status
------------------------------------------------------------
* 0 /usr/lib/openblas-base/libopenblas.so.0 40 auto mode
1 /usr/lib/atlas-base/atlas/libblas.so.3gf 35 manual mode
2 /usr/lib/libblas/libblas.so.3gf 10 manual mode
3 /usr/lib/openblas-base/libopenblas.so.0 40 manual mode
Press enter to keep the current choice[*], or type selection number:

Side note: If the above returned:

 update-alternatives: error: no alternatives for libblas.so.3gf

Try

 sudo update-alternatives --config libblas.so.3
Pogy answered 13/6, 2014 at 17:14 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.