gmane.comp.lang.r.hpc

fork() warning from mpi

Jim Maas — 2012-05-19T14:11:13

I get the following message when running a job using R 2.15.0, Rmpi, 
doMPI, and a cluster system that uses a LSF operating system and 
infiniband connections.  I'm just a user and know little about the 
workings of such networks but the warning unsettles me a little.  I've 
asked people who write and maintain open-mpi and they are suggesting 
that something has changed in the latest version of R that causes this.

I'm wondering if there has been a change or if we have done something 
incorrectly when installing Rmpi on the system, not sure here but this 
might have to be built/compiled against open-mpi libraries.  The 
open-mpi people have suggested that R must be doing some king of fork 
after the call MPI-Init.

Could anyone tell me if this is a new problem, or have we done something 
incorrectly?  I have a toy model file that creates it and am happy to 
supply this.

Thanks a bunch,

J

===============================
An MPI process has executed an operation involving a call to the
"fork()" system call to create a child process.  Open MPI is currently
operating in a condition that could result in memory corruption or
other system errors; your MPI job may hang, crash, or produce silent
data corruption.  The use of fork() (or system() or other calls that
create child processes) is strongly discouraged.

The process that invoked fork was:

   Local host:          cn149.private.dns.zone (PID 27492)
   MPI_COMM_WORLD rank: 21

If you are *absolutely sure* that your application will successfully
and correctly survive a call to fork(), you may disable this warning
by setting the mpi_warn_on_fork MCA parameter to 0.
===========================

Jim Maas
University of East Anglia

New version of cloudRmpi

Barnet Wagman — 2012-05-14T16:07:18

cloudRmpi v 1.2 is now available on CRAN.

cloudRmpi is a means for doing parallel processing in R, using MPI on a  
cloud-based network.  It currently
supports the use of Amazon's EC2 cloud computer service.

Changes in v 1.2:

Support for RStudio. RStudio Server is available on new AMIs.  cloudRmpi 
now has a function for securely connecting to an RStudio session running 
on the master node of an EC2-MPI network, via ssh port forwarding.  
(RStudio Server is a browser based, IDE-like interface to R).

The network specification dialog shows more information about AMIs.

The network manager has a command to repeat Open MPI network network 
configuration.


Regards,

Barnet Wagman

Condor, grid-appliance or pool-of-virtual machine

Stefan Janse van Rensburg — 2012-05-14T11:08:14

Dear List,

I am hoping somebody would be kind enough to share their recent 
experiences with R and Condor or R and BOINC. I am aware of the November 
2005 RNews article, but I would think that a lot has happened in this 
area since then. E.g. The gridR package.

I am writing a preliminary report on the viability of implementing some 
form of a grid computing setup for cycle-scavanging at Rhodes 
University, South Africa. Most of our lab machines are Windows XP and 7 
desktops. My preliminary readings suggest that running a VM with Linux 
guest OS would be the best option. Is see that there are several 
pre-prepared bundles for this sort of thing, such as Grid Appliance and 
Pool-of-Virtual Machines. Has any one used any of these with R?

Any help, whatsoever, would be much appreciated.

Kind regards,

Stefan Janse van Rensburg 
<http://www.ru.ac.za/statistics/staff/mrstefanjansevanrensburg/>

<http://www.ru.ac.za/statistics/staff/mrstefanjansevanrensburg/>

Lecturer, Dept. of Statistics, Rhodes University

Tel: +27-046-603-8682

--

Visit my public photo album... 
<https://picasaweb.google.com/102772614620404730049?feat=email>




[[alternative HTML version deleted]]

Re: Quickest way to make a large "empty" file on disk?

Jonathan Greenberg — 2012-05-03T15:44:34

Thanks, all!  I'll try these out.  I'm trying to work up something that is
platform independent (if possible) for use with mmap.  I'll do some tests
on these suggestions and see which works best. I'll try to report back in a
few days.  Cheers!

--j



2012/5/3 "Jens Oehlschlägel" <jens.oehlschlaegel-vIO29ytYk2YIjDr1QQGPvw< at >public.gmane.org>

Re: Quickest way to make a large "empty" file on disk?

Simon Urbanek — 2012-05-03T01:08:14

On May 2, 2012, at 6:23 PM, Jonathan Greenberg wrote:


The most trivial way is to simply seek to the end and write a byte:

[1] 0
[1] 1e+05

Cheers,
Simon

Re: Quickest way to make a large "empty" file on disk?

Jeff Ryan — 2012-05-02T22:57:39

Something like:

http://markus.revti.com/2007/06/creating-empty-file-with-specified-size/

Is one way I know of. 

Jeff

Jeffrey Ryan    |    Founder    |    jeffrey.ryan-YZRdihq200hBDgjK7y7TUQ< at >public.gmane.org

www.lemnica.com

On May 2, 2012, at 5:23 PM, Jonathan Greenberg <jgrn-nzINlOoChub2fBVCVOL8/A< at >public.gmane.org> wrote:

Re: Quickest way to make a large "empty" file on disk?

Jeff Ryan — 2012-05-02T22:42:37

Look at the man page for dd (assuming you are on *nix)

A quick google will get you a command to try. I'm not at my desk or I would as well. 

Jeff

Jeffrey Ryan    |    Founder    |    jeffrey.ryan-YZRdihq200hBDgjK7y7TUQ< at >public.gmane.org

www.lemnica.com

On May 2, 2012, at 5:23 PM, Jonathan Greenberg <jgrn-nzINlOoChub2fBVCVOL8/A< at >public.gmane.org> wrote:

Quickest way to make a large "empty" file on disk?

Jonathan Greenberg — 2012-05-02T22:23:35

R-helpers:

What would be the absolute fastest way to make a large "empty" file (e.g.
filled with all zeroes) on disk, given a byte size and a given number
number of empty values.  I know I can use writeBin, but the "object" in
this case may be far too large to store in main memory.  I'm asking because
I'm going to use this file in conjunction with mmap to do parallel writes
to this file.  Say, I want to create a blank file of 10,000 floating point
numbers.

Thanks!

--j

Analytics & Data Mining Conference, San Diego,California

Lisa Solomon — 2012-05-02T19:08:35

Subject: Analytics & Data Mining Conference, San Diego, California

Don't miss it, it's this month!

The 2012 Salford Analytics & Data Mining Conference aims to bring together
researchers, practitioners, and data enthusiasts to exchange ideas and
experiences.

Attendees will have the chance to have one-on-one meetings with the creators of the CART and RandomForests algorithms
(Dr. Adele Cutler, Dr. Jerome Friedman and Dr. Richard Olshen).

In addition, the following companies will give presentations:
Johnson & Johnson, Genentech, Visa, Fidelity, Qualcomm, Union Bank and more!

Conference website: http://www.salforddatamining.com/
Agenda: http://www.salforddatamining.com/agenda.html
Registration: http://www.salforddatamining.com/register.html

For additional information, contact info-JdWS0y8hGXeRvUXW8jGz4vpXobYPEAuW< at >public.gmane.org<mailto:info-JdWS0y8hGXeRvUXW8jGz4vpXobYPEAuW< at >public.gmane.org> or phone 619-543-8880.

Best regards,
Lisa Solomon
lisas-8ugdV5V/5NuhEniVeURVKkEOCMrvLtNR< at >public.gmane.org<mailto:lisas-8ugdV5V/5NuhEniVeURVKkEOCMrvLtNR< at >public.gmane.org>
Salford Systems

[[alternative HTML version deleted]]

Re: 'Rmpi' issue

Libo Sun — 2012-04-30T21:14:43

Thanks for your good advice.

I changed to R 2.14.1 and Rmpi works fine. :)

However, there is another problem when I try to use snow package.

This is error message I got:

MPI: bl1.psc.teragrid.org: 0x54e500004f90ba1f: /bin/sh: line 0: exec:
RMPISNOW: not found

I am sure RMPISNOW is in the working directory.

Thanks,
Libo

On Mon, Apr 30, 2012 at 7:10 AM, Stephen Weston
<stephen.b.weston-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote:


[[alternative HTML version deleted]]

Re: 'Rmpi' issue

Paul Johnson — 2012-04-30T06:24:21

Greetings,

You'll have to spend more time studying the basics of creating a
cluster inside R and talking to its nodes.


Your R program is not complete enough to create a cluster and talk to
it, try some examples I have here for working code.

http://web.ku.edu/~quant/cgi-bin/mw1/index.php?title=Cluster:Main#R_Packages_and_Parallel_Computing

Go to the hpcexample archive, something like:

http://winstat.quant.ku.edu/svn/hpcexample/trunk/Ex53-HelloWorldRmpi

or
http://winstat.quant.ku.edu/svn/hpcexample/trunk/Ex60-HelloWorldSnow


You appear to have a very ancient R, if 2.11 is what I see there.  I'd
not bother with such an old setup. Do  you even know for sure if Rmpi
is working there?  Can't your system admin give you a working example?

You will probably need to know more about your cluster, I don't have
time to study up on that for you.  The error messages are suspiciously
like an MS Windows system.  That would be surprising.  On a Linux
cluster, I've never seen a dynLoad message like you have.



On Sun, Apr 29, 2012 at 11:07 PM, Libo Sun <libosun-kQrko9EuJtOVG/+Gxqlb8De48wsgrGvP< at >public.gmane.org> wrote:

'Rmpi' issue

Libo Sun — 2012-04-30T04:07:51

Hi,

I am trying to test 'Rmpi' on Blacklight,
http://www.psc.edu/machines/sgi/uv/blacklight.php, in PSC.

The R code I am trying to run is very simple:

mpi.remote.exec(paste("I am",mpi.comm.rank(),"of",mpi.comm.size()))
mpi.remote.exec(paste("I am",Sys.info()1,"of",mpi.comm.size()))

The batch file:

#!/bin/csh
#PBS -l walltime=5:00
#PBS -l ncpus=16
#PBS -o test.out
#PBS -j oe
#PBS -q debug

# define module command
source /usr/share/modules/init/csh

set echo
date

# load R module
module load R/2.11.1
module load Rmpi
module swap mpt/2.04 mpt/2.01

# move to scratch space to run job
cd $SCRATCH

# copy input file to scratch space
cp $HOME/test.R .
cp $HOME/.Rprofile .

mpirun -np 16 R --no-save -q < test.R > test.Rout

However, here are some error messages I got:

 *** caught segfault ***
address (nil), cause 'memory not mapped'

Traceback:
 1: dyn.load(file, DLLpath = DLLpath, ...)
 2: library.dynam("Rmpi", pkg, lib)
 3: f(libname, pkgname)
 4: firstlib(which.lib.loc, package)
 5: doTryCatch(return(expr), name, parentenv, handler)
 6: tryCatchOne(expr, names, parentenv, handlers[[1L]])
 7: tryCatchList(expr, classes, parentenv, handlers)
 8: tryCatch(expr, error = function(e) {    call <- conditionCall(e)    if
(!is.null(call)) {        if (identical(call[[1L]],
quote(doTryCatch)))             call <- sys.call(-4L)        dcall <-
deparse(call)[1L]        prefix <- paste("Error in", dcall, ": ")
LONG <- 75L        msg <- conditionMessage(e)        sm <- strsplit(msg,
"\n")[[1L]]        w <- 14L + nchar(dcall, type = "w") + nchar(sm[1L], type
= "w")        if (is.na(w))             w <- 14L + nchar(dcall, type = "b")
+ nchar(sm[1L],                 type = "b")        if (w >
LONG)             prefix <- paste(prefix, "\n  ", sep = "")    }    else
prefix <- "Error : "    msg <- paste(prefix, conditionMessage(e), "\n", sep
= "")    .Internal(seterrmessage(msg[1L]))    if (!silent &&
identical(getOption("show.error.messages"),         TRUE)) {
cat(msg, file = stderr())        .Internal(printDeferredWarnings())    }
invisible(structure(msg, class = "try-error"))})
 9: try(firstlib(which.lib.loc, package))
10: library(Rmpi, logical.return = TRUE)
aborting ...

Any idea how to fix this?

Many thanks,
Libo

[[alternative HTML version deleted]]

Re: parallel and openblas

Dirk Eddelbuettel — 2012-04-25T19:19:42

On 25 April 2012 at 14:38, Simon Urbanek wrote:
| FWIW: Based on this discussion, I have added the capability to manage CPU affinity mask in R-devel. In the short term you can use mcaffinity() to control the affinity yourself, so for example mcaffinity(1:ncores) will allow R to run on any core or you can restrict your parallel jobs to certain CPU ranges. Eventually, R/parallel should handle that for you by partitioning cores to child processes (we are missing mandatory core detection and tracking to do that), for now the closest you get is mc.affiinity in mcparallel() to spread children yourself.

That sounds like the great addition!  It is hard to find 'one size fits all'
settings, particularly for a distribution, and having control / a toggle to
adjust seems like a nice improvement.

Thanks, Dirk

Re: parallel and openblas

Simon Urbanek — 2012-04-25T18:38:53

FWIW: Based on this discussion, I have added the capability to manage CPU affinity mask in R-devel. In the short term you can use mcaffinity() to control the affinity yourself, so for example mcaffinity(1:ncores) will allow R to run on any core or you can restrict your parallel jobs to certain CPU ranges. Eventually, R/parallel should handle that for you by partitioning cores to child processes (we are missing mandatory core detection and tracking to do that), for now the closest you get is mc.affiinity in mcparallel() to spread children yourself.

Cheers,
Simon


On Apr 25, 2012, at 12:54 PM, Claudia Beleites wrote:

Re: parallel and openblas

Claudia Beleites — 2012-04-25T16:54:03

I agree with Simon.

- Not restricting the children doesn't lead to problems with both
implicit and explicit parallelization for me:
E.g. if I decide to run explicitly 3 parallel threads and have 12 cores,
I use GOTO_NUM_THREADS 4, and that works nicely.

- if users do not have access to taskset, then restriction to 1 core is
certainly more problematic than no restriction.

Claudia



Am 25.04.2012 17:21, schrieb Simon Urbanek:

Re: parallel and openblas

Simon Urbanek — 2012-04-25T15:21:27

On Apr 25, 2012, at 11:10 AM, Dirk Eddelbuettel wrote:


I'd argue that the problem is affinity of 1 by default - that is certainly not what you want or expect and bad in most cases. It would make much more sense to restrict the *children* to one CPU each rather than the parent process so that forked processes stay on their cores - that is IMHO the only place where setting affinity makes any sense at all. Also the system(..) trick is ugly and highly system-specific (you don't even know if you can access taskset). I would consider OpenBLAS' affinity setting as a pretty bad bug (certainly form user's point of view).

Cheers,
Simon

Re: parallel and openblas

Dirk Eddelbuettel — 2012-04-25T15:10:26

Sorry to follow-up on my own post from minutes ago, but maybe it is better
the way it is as it allows to explicitly spread tasks each of which would
limit itself to one core.  Isn't this the best way to avoid "clogging" when
we use, say, snow to get to eight cores, and each of the eight cores wants to
do BLAS work on eight cores...  That was after all the initial issue in
Martin's email.

And when I use the affinity trick (now breaking the single line for display)

  edd< at >max:~$ r -e 'library(parallel); \
                   system(sprintf("taskset -p 0xffffffff %d", Sys.getpid())); \
                   cores <- detectCores(); \
                   print(cores); \
                   mclapply(1:cores, function(i) repeat sqrt(3.14159), mc.cores=cores)'
  pid 24436's current affinity mask: 1
  pid 24436's new affinity mask: ff
  [1] 8

all is well -- eight cores humming along just fine per htop under OpenBLAS.  

Maybe this is actually better as it effectively gives us a run-time toggle?

Dirk

Re: parallel and openblas

Dirk Eddelbuettel — 2012-04-25T14:50:01

[ 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-8fiUuRrzOP0dnm+yROfE0A< at >public.gmane.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

Re: parallel and openblas

Stephen Weston — 2012-04-25T14:24:14

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"

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.

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.

- Steve

On Tue, Apr 24, 2012 at 8:37 PM, Dirk Eddelbuettel <edd-8fiUuRrzOP0dnm+yROfE0A< at >public.gmane.org> wrote:

Re: parallel and openblas

Dirk Eddelbuettel — 2012-04-25T12:28:48

This is getting off-topic for r-sig-hpc ...

On 24 April 2012 at 19:10, M. Edward (Ed) Borasky wrote:
| On Tue, Apr 24, 2012 at 5:39 PM, Dirk Eddelbuettel <edd-8fiUuRrzOP0dnm+yROfE0A< at >public.gmane.org> wrote:
| 
| > Too much credit. I "merely" take care of R (and Octave earlier on). This is
| > distributed work, and the Atlas (and other BLAS) maintainers, starting with
| > Camm and now Sylvestre, are doing an amazing job. I simply know how to reuse
| > that to R's benefit.
| 
| Speaking of packaging for distros, it looks like the OpenSUSE Build
| Service has some semi-automated setup for grabbing Perl packages from
| CPAN and wrapping them up as RPMs. I haven't dug into it, but I've
| been seeing all sorts of useful things show up in the repositories. If
| it can be done for CPAN using the OpenSUSE Build Service testing /
| building infrastructure, it ought to be possible for CRAN as well. And
| the infrastructure is capable of packaging for all the major distros,
| not just openSUSE.

Go for it. 

After roughly a decade's work, and around four or five different attempts, we
now have an archive for 'apt-get r-cran-$ANYTHING' for Ubuntu (that is,
Michael Rutter's PPA on launchpad covering different Ubuntu builds) as well
as one for Debian (that is, Don Armstrong's debian-r.debian.net covering
Debian testing and now stable as well).

So it can be done, but there is a lot of detailed work underneath it. And
it's nice to have, especially for clusters as it minimizes per-node work and
keeps them in sync.

And it all started with the cran2deb work we did based on Albrecht's script
written initially for ... OpenSUSE and then ported to Debian. What goes
around comes around.

Dirk

Re: parallel and openblas

M. Edward (Ed) Borasky — 2012-04-25T02:10:01


Speaking of packaging for distros, it looks like the OpenSUSE Build
Service has some semi-automated setup for grabbing Perl packages from
CPAN and wrapping them up as RPMs. I haven't dug into it, but I've
been seeing all sorts of useful things show up in the repositories. If
it can be done for CPAN using the OpenSUSE Build Service testing /
building infrastructure, it ought to be possible for CRAN as well. And
the infrastructure is capable of packaging for all the major distros,
not just openSUSE.