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 t

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

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:li

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

'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),

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:

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"

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 rou

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.