[R-sig-hpc] parallel and openblas

Dirk Eddelbuettel edd at debian.org
Wed Apr 25 16:50:01 CEST 2012


[ Sylvestre: I am tossing you in the middle of a thread here. We may have a
buglet in OpenBLAS where NO_AFFINITY=1 might be a good config value to add. ]

Steve,

Nice work, and mostly confirming against OpenBLAS, Atlas and a local (old)
GotoBLAS2. 

On 25 April 2012 at 10:24, Stephen Weston wrote:
| I was able to confirm that when I built R using OpenBLAS on my
| Linux machine, my CPU affinity was modified right at the
| beginning of the R session:
| 
|   $ grep Cpus_allowed /proc/self/status
|   Cpus_allowed: ffffffff,ffffffff
|   Cpus_allowed_list:    0-63
|   $ bin/R
|   > readLines('/proc/self/status')[32]
|   [1] "Cpus_allowed:\t00000000,00000001"

What kernel is that?  On 3.0.0-17 (Ubuntu 11.10, infrequently rebooted) I get 

  edd at max:~$ grep Cpus_allowed /proc/self/status
  Cpus_allowed:   ff
  Cpus_allowed_list:      0-7
  edd at max:~$

| I then confirmed that this causes problems for parallel packages
| such as "parallel" by trying to use all six cores of my machine
| using the "mclapply" function:
| 
|   > library(parallel)
|   > cores <- detectCores()
|   > mclapply(1:cores, function(i) repeat sqrt(3.14159), mc.cores=cores)
| 
| When I executed "top" from another window and pressed "1", it
| showed that only one core was being used, and there were six R
| sessions, each getting 17% of the CPU.

When I run these three commands as a single line for r (from the littler package)

  edd at max:~$ r -e 'library(parallel);  cores <- detectCores(); print(cores); mclapply(1:cores, function(i) repeat sqrt(3.14159), mc.cores=cores)'
  [1] 8
  ^C
  edd at max:~$ 

I also get just one core covered. That is with 

  edd at max:~$ COLUMNS=94 dpkg -l|grep "blas\|atlas" | cut -c-78
  ii  gotoblas2-helper  0.1-12.local.1    GotoBLAS2 helper
  ii  libblas-dev       1.2.20110419-2ubu Basic Linear Algebra Subroutines 3, st
  ii  libblas-test      1.2.20110419-2ubu Basic Linear Algebra Subroutines 3, te
  ii  libblas3gf        1.2.20110419-2ubu Basic Linear Algebra Reference impleme
  ii  libopenblas-base  0.1alpha2.2-3     Optimized BLAS (linear algebra) librar
  ii  libopenblas-dev   0.1alpha2.2-3     Optimized BLAS (linear algebra) librar
  edd at max:~$ 

where OpenBLAS provides BLAS as default.

That was after I had removed Atlas which is still my default. So if I
reiinstall Atlas (which "ranks higher" in the defaults and hence replaces
OpenBLAS) everything is fine -- eight cores used.

  edd at max:~$ COLUMNS=94 dpkg -l|grep "blas\|atlas" | cut -c-78
  ii  gotoblas2-helper  0.1-12.local.1    GotoBLAS2 helper
  ii  libatlas-base-dev 3.8.4-3build1     Automatically Tuned Linear Algebra Sof
  ii  libatlas-dev      3.8.4-3build1     Automatically Tuned Linear Algebra Sof
  ii  libatlas3gf-base  3.8.4-3build1     Automatically Tuned Linear Algebra Sof
  ii  libblas-dev       1.2.20110419-2ubu Basic Linear Algebra Subroutines 3, st
  ii  libblas-test      1.2.20110419-2ubu Basic Linear Algebra Subroutines 3, te
  ii  libblas3gf        1.2.20110419-2ubu Basic Linear Algebra Reference impleme
  ii  libopenblas-base  0.1alpha2.2-3     Optimized BLAS (linear algebra) librar
  ii  libopenblas-dev   0.1alpha2.2-3     Optimized BLAS (linear algebra) librar
  edd at max:~$ 
 
 
| I also confirmed that "Cpus_allowed" was being set to the same
| value for each of the workers:
| 
|   > mclapply(1:cores, function(i) readLines('/proc/self/status')[32],
| mc.cores=cores)
|   [[1]]
|   [1] "Cpus_allowed:\t00000000,00000001"
| 
|   [[2]]
|   [1] "Cpus_allowed:\t00000000,00000001"
| 
|   [[3]]
|   [1] "Cpus_allowed:\t00000000,00000001"
| 
|   [[4]]
|   [1] "Cpus_allowed:\t00000000,00000001"
| 
|   [[5]]
|   [1] "Cpus_allowed:\t00000000,00000001"
| 
|   [[6]]
|   [1] "Cpus_allowed:\t00000000,00000001"
| 
| That is definitely not what you want to see, and explains why
| "mclapply" is only able to use one core.
| 
| When I rebuilt and reinstalled OpenBLAS after editing
| Makefile.rule so that it contained the line:
| 
|   NO_AFFINITY = 1
| 
| and then restarted R, the problem went away:
| 
|   $ bin/R
|   > readLines('/proc/self/status')[32]
|   [1] "Cpus_allowed:\tffffffff,ffffffff"
| 
| This time when I ran "mclapply", "top" confirmed that I was
| using all six cores at about 100%.
| 
| I didn't try this experiment with the older GotoBLAS2, but I
| believe the results would be the same.

I can confirm this. Using the packages 

edd at max:~$ COLUMNS=94 dpkg -l|grep "blas\|atlas" | cut -c-78
ii  gotoblas2         1.13-1            GotoBLAS2
ii  gotoblas2-helper  0.1-12.local.1    GotoBLAS2 helper
ii  libblas-dev       1.2.20110419-2ubu Basic Linear Algebra Subroutines 3, st
ii  libblas-test      1.2.20110419-2ubu Basic Linear Algebra Subroutines 3, te
ii  libblas3gf        1.2.20110419-2ubu Basic Linear Algebra Reference impleme
edd at max:~$

where the GotoBLAS2 (locally built, using the gotoblas2-helper package) now
provide BLAS, everything sticks to one core when running the mclapply.  

I guess I'd need to fix gotoblas2-helper and rebuild the gotoblas2.  Or stick
with / hope for a corrected OpenBLAS build.

Dirk
 
| - Steve
| 
| 
| On Tue, Apr 24, 2012 at 8:37 PM, Dirk Eddelbuettel <edd at debian.org> wrote:
| >
| > On 24 April 2012 at 15:45, Stephen Weston wrote:
| > | There's an interesting discussion entitled "all processes run on
| > | one CPU core" at:
| > |
| > |     https://github.com/ipython/ipython/issues/840
| > |
| > | Someone was experiencing a very similar problem to the one that
| > | Claudia described using GotoBLAS2 with IPython and NumPy.
| > | Apparently it was fixed by recompiling GotoBLAS2 with the
| > | "NO_AFFINITY" parameter set to "1" in Makefile.rule, and then
| > | rebuilding "NumPy".
| > |
| > | It seems pretty strange, but GotoBLAS2/OpenBLAS may be modifying
| > | the affinity of the R process by calling sched_setaffinity() when
| > | it is initialized, and that is causing the problems that Claudia
| > | and Martin have seen.
| > |
| > | So perhaps the solution is to recompile GotoBLAS2/OpenBLAS with
| > | NO_AFFINITY=1, and then rebuild R with it.
| >
| > Good discussion, but one important nit: never a need to rebuild a R (provided
| > you have external / dynamically linked BLAS).
| >
| > Just restart R.
| >
| > Dirk
| >
| > --
| > R/Finance 2012 Conference on May 11 and 12, 2012 at UIC in Chicago, IL
| > See agenda, registration details and more at http://www.RinFinance.com

-- 
R/Finance 2012 Conference on May 11 and 12, 2012 at UIC in Chicago, IL
See agenda, registration details and more at http://www.RinFinance.com



More information about the R-sig-hpc mailing list