[Rd] R with ATLAS avoids Linux cpu affinity
Hi all, I have a problem with cpu affinity in my R-2.11.1 installation compiled against ATLAS running on a Linux (Ubuntu 10.04) cluster under GridEngine. I wish to use Grid Engine's core binding feature to bind user processes into the number of cores they request on the cluster, thus preventing badly behaved multi-threaded libraries from consuming more cores than requested. An example of this is R compiled against multithreaded ATLAS, which needs to be bound into a single core if a user submits a 1 core job. Grid Engine achieves this through the sched_setaffinity system call under Linux 2.6. For most applications (including if I write a test C program that uses ATLAS BLAS), this works well, and prevents threads from 'leaking' outside the cpu set they are assigned. However, R appears to be able to avoid the core binding. This is *very* strange as I was under the impression that any child processes or threads inherit the cpu affinity of the parent. Does anyone have experience of this and could offer a comment or solution? Thanks, Chris -- Dr Chris Jewell Department of Statistics University of Warwick Coventry CV4 7AL UK Tel: +44 (0)24 7615 0778 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R with ATLAS avoids Linux cpu affinity
Chris, On 6 December 2010 at 15:43, Chris Jewell wrote: | Hi all, | | I have a problem with cpu affinity in my R-2.11.1 installation compiled against ATLAS running on a Linux (Ubuntu 10.04) cluster under GridEngine. I wish to use Grid Engine's core binding feature to bind user processes into the number of cores they request on the cluster, thus preventing badly behaved multi-threaded libraries from consuming more cores than requested. An example of this is R compiled against multithreaded ATLAS, which needs to be bound into a single core if a user submits a 1 core job. Grid Engine achieves this through the sched_setaffinity system call under Linux 2.6. For most applications (including if I write a test C program that uses ATLAS BLAS), this works well, and prevents threads from 'leaking' outside the cpu set they are assigned. However, R appears to be able to avoid the core binding. This is *very* strange as I was under the impression that any child processes or threads inherit the cpu affinity of the parent. | | Does anyone have experience of this and could offer a comment or solution? Atlas will _always_ use all the cores 'compiled in'. Ubuntu's current package just uses one (as it is not a multithreaded build). This will change with future package as per the Debian / Ubuntu package maintainer. If you built Atlas locally, you may be use all cores (depending on how you built). There is simply no way to 'scale up or down' dynamically with Atlas -- but both MKL and GotoBLAS2 can do this. See my package / paper on BLAS and GPU benchmarking (cf http://dirk.eddelbuettel.com/blog/code/gcbd/ for two posts and links) for details. AFAICT R should not alter CPU affinity. So if I were you I'd swap the BLAS implementation and try again. As you are on Ubuntu, you can try the MKL that comes with the (now a littler older) Revolution R in Ubuntu 9.10; otherwise I can highly recommend the GotoBLAS2 helper package listed in my paper for a local GotoBLAS2 built. The script may be out of sync with the fairly recent license change of GotoBLAS2 (to the more liberal BSD license permitting redistribution). With some luck we will GotoBLAS2 deb packages in future Debian and Ubuntu releases. Hth, Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Competing with one's own work
Ben raised an interesting point: A better question might be how packages get added to the *recommended* package list (rather than how code gets added to base R). As maintainer of survival one of the surprising things is the number of packages that depend on mine. This has caused me to change my opinion over the last few years about how much expansion of the package should occur. I used to feel bad that the package doesn't keep up with everything, now I tend to vote for putting new ideas elsewhere. Consider competing risks for instance. The cleanest way to code this is to extend the Surv(time, status) construct to allow more than a 0/1 status variable. I thought about this seriously, and realized that such a change would have ripple effects on some of the other routines -- an extra if statement here and there. This is doable, but what about the effect on the 153 dependent packages! The stability of survival is now more important than its feature set. My first extention to random effects (a very simplistic one) was incorporated into the main survival package. I've pushed the later developments into thier own package. It was definitely the right choice. Terry T __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] when to use pairlist instead list
I was writing some assertion tests for modelling-related code I had written and was surprised to see one test fail because the specials attribute of the output of terms() is a pairlist instead of a list. In 2.12.0 I get: dput(attr(terms(y~Spec(x1)+x2, specials=c(Spec)), specials)) list(Spec = 2L) all.equal(attr(terms(y~Spec(x1)+x2, specials=c(Spec)), specials), list(Spec=2L)) [1] Modes: pairlist, list all.equal(attr(terms(y~Spec(x1)+x2, specials=c(Spec)), specials), pairlist(Spec=2L)) [1] TRUE identical(attr(terms(y~Spec(x1)+x2, specials=c(Spec)), specials), pairlist(Spec=2L)) [1] TRUE I was wondering if there was a reason for using pairlist instead of list here or it it was just an historical artifact. In general, when should one use pairlists? Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem installing RCurl
Thank you both for your reply. After reading your responses, I removed the existing CSWcurl, and compiled curl-7.21.2 from source using solstudio (the same compiler I got R-2.12.0 in place) to /opt/csw. Tried to install RCurl, I got the same error, the only difference is the include file's line number, /opt/csw/include/curl/curlrules.h, line 143: zero or negative subscript The line 143 is the third line of the following, the variable must have been defined outside the file. typedef char __curl_rule_01__ [CurlchkszEQ(long, CURL_SIZEOF_LONG)]; I don't know what value the compiler expect, but can I define it here if I know? As to the bit, this machine's got 64G memory, I simply has no choice but to compile 64-bit R. Jun -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Prof Brian Ripley Sent: Saturday, December 04, 2010 1:03 AM To: Duncan Temple Lang Cc: r-devel@r-project.org Subject: Re: [Rd] Problem installing RCurl On Fri, 3 Dec 2010, Duncan Temple Lang wrote: Hi Jun On 12/3/10 2:15 PM, Zhang,Jun wrote: I have 64-bit R 2 12 0 installed on Solaris 10 of Sun Sparc. When I tried to install RCurl, it failed with the following lines, ... Version has CURLOPT_SSL_SESSIONID_CACHE libcurl version: libcurl 7.19.6 configure: creating ./config.status config.status: creating src/Makevars ** libs cc -xc99 -m64 -xarch=sparcvis2 -I/apps/sparcv9/R-2.12.0/lib/R/include -I/opt/csw/include -DHAVE_LIBIDN_FIELD=1 -DHAVE_CURLOPT_URL=1 -DHAVE_CURLINFO_EFFECTIVE_URL=1 .(omitted here is very long, all upper case) -DHAVE_CURLOPT_SSL_SESSIONID_CACHE=1 -I/opt/csw/include-KPIC -xcode=abs64 -xlibmieee -xtarget=ultra3 -xarch=sparcvis2 -c base64.c -o base64.o /opt/csw/include/curl/curlrules.h, line 144: zero or negative subscript This error indicates that the compiler (cc with flags -xc99 -m64, etc.) sees the size of the 'long' data type in C is different from what was seen when libcurl was configured, built and installed. So basically the compiler and/or the compiler flags were different. How was libcurl installed - from source or from a pre-built binary ? What compiler and flags were used? The header is from a prebuilt binary (from OpenCSW). That is built with gcc and not the Sun compiler. And curlbuild.h says /* Allow 32 and 64 bit headers to coexist */ #if defined __amd64 || defined __x86_64 || defined __sparcv9 #include curlbuild-64.h #else #include curlbuild-32.h #endif which AFAIK are gcc and not Sun defines. You could try adding -D__sparcv9 to the CPPFLAGS, or compile RCurl with OpenCSW's gcc build (but 64-bit gcc is another can of worms). I've pointed out to Jun Zhang several times that 64-bit Sparc Solaris is really pushing it, and 32-bit R on Sparc Solaris has been much more successful. Given that x86_64 boxes (Solaris or Linux) are so much faster at computation than Sparc ones, I don't see the point of building 64-bit Sparc Solaris R -- if 32-bit R is not enough you need a faster machine. D. base64.c, line 25: warning: assignment type mismatch: pointer to const char = pointer to unsigned char base64.c, line 39: warning: argument #1 is incompatible with prototype: prototype: pointer to const char : /apps/sparcv9/R-2.12.0/lib/R/include/Rinternals.h, line 1042 argument : pointer to unsigned char base64.c, line 60: warning: assignment type mismatch: pointer to const char = pointer to unsigned char cc: acomp failed for base64.c make: *** [base64.o] Error 2 ERROR: compilation failed for package 'RCurl' * removing '/apps/sparcv9/R-2.12.0/lib/R/library/RCurl' The downloaded packages are in '/tmp/Rtmpo67mNX/downloaded_packages' Updating HTML index of packages in '.Library' Warning message: In install.packages(RCurl) : installation of package 'RCurl' had non-zero exit status What is the problem? Jun [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] when to use pairlist instead list
On Mon, 6 Dec 2010, William Dunlap wrote: I was writing some assertion tests for modelling-related code I had written and was surprised to see one test fail because the specials attribute of the output of terms() is a pairlist instead of a list. In 2.12.0 I get: dput(attr(terms(y~Spec(x1)+x2, specials=c(Spec)), specials)) list(Spec = 2L) all.equal(attr(terms(y~Spec(x1)+x2, specials=c(Spec)), specials), list(Spec=2L)) [1] Modes: pairlist, list all.equal(attr(terms(y~Spec(x1)+x2, specials=c(Spec)), specials), pairlist(Spec=2L)) [1] TRUE identical(attr(terms(y~Spec(x1)+x2, specials=c(Spec)), specials), pairlist(Spec=2L)) [1] TRUE I was wondering if there was a reason for using pairlist instead of list here or it it was just an historical artifact. In general, when should one use pairlists? Probably never directly. But indirectly, a lot as for example argument lists are pairlists. Looking at the code, I think this one is simply history. For completeness I will correct ?terms.object. -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R with ATLAS avoids Linux cpu affinity
On 6 Dec 2010, at 16:03, Dirk Eddelbuettel wrote: AFAICT R should not alter CPU affinity. So if I were you I'd swap the BLAS implementation and try again. As you are on Ubuntu, you can try the MKL that comes with the (now a littler older) Revolution R in Ubuntu 9.10; otherwise I can highly recommend the GotoBLAS2 helper package listed in my paper for a local GotoBLAS2 built. The script may be out of sync with the fairly recent license change of GotoBLAS2 (to the more liberal BSD license permitting redistribution). With some luck we will GotoBLAS2 deb packages in future Debian and Ubuntu releases. Thanks for the comments, Dirk. I take your point about ATLAS having the cores compiled in. I have replaced ATLAS with ACML, and all works fine. Cheers, Chris -- Dr Chris Jewell Department of Statistics University of Warwick Coventry CV4 7AL UK Tel: +44 (0)24 7615 0778 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem installing RCurl
I tried to give CPPFLAGS the value -D__sparcv9, the compiler complaint about cross compiling. And then I tried CPPFLAGS=-D__sparcv9 -U__sparcv8, export it, installation of curl-7.21.2 is fine, but give me just the 32-bit result. Any hint will be appreciated to buil the 64-bit curl (only then I have hope to install RCurl). Jun -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Zhang,Jun Sent: Monday, December 06, 2010 1:27 PM To: 'Prof Brian Ripley'; 'Duncan Temple Lang' Cc: 'r-devel@r-project.org' Subject: Re: [Rd] Problem installing RCurl Thank you both for your reply. After reading your responses, I removed the existing CSWcurl, and compiled curl-7.21.2 from source using solstudio (the same compiler I got R-2.12.0 in place) to /opt/csw. Tried to install RCurl, I got the same error, the only difference is the include file's line number, /opt/csw/include/curl/curlrules.h, line 143: zero or negative subscript The line 143 is the third line of the following, the variable must have been defined outside the file. typedef char __curl_rule_01__ [CurlchkszEQ(long, CURL_SIZEOF_LONG)]; I don't know what value the compiler expect, but can I define it here if I know? As to the bit, this machine's got 64G memory, I simply has no choice but to compile 64-bit R. Jun -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Prof Brian Ripley Sent: Saturday, December 04, 2010 1:03 AM To: Duncan Temple Lang Cc: r-devel@r-project.org Subject: Re: [Rd] Problem installing RCurl On Fri, 3 Dec 2010, Duncan Temple Lang wrote: Hi Jun On 12/3/10 2:15 PM, Zhang,Jun wrote: I have 64-bit R 2 12 0 installed on Solaris 10 of Sun Sparc. When I tried to install RCurl, it failed with the following lines, ... Version has CURLOPT_SSL_SESSIONID_CACHE libcurl version: libcurl 7.19.6 configure: creating ./config.status config.status: creating src/Makevars ** libs cc -xc99 -m64 -xarch=sparcvis2 -I/apps/sparcv9/R-2.12.0/lib/R/include -I/opt/csw/include -DHAVE_LIBIDN_FIELD=1 -DHAVE_CURLOPT_URL=1 -DHAVE_CURLINFO_EFFECTIVE_URL=1 .(omitted here is very long, all upper case) -DHAVE_CURLOPT_SSL_SESSIONID_CACHE=1 -I/opt/csw/include-KPIC -xcode=abs64 -xlibmieee -xtarget=ultra3 -xarch=sparcvis2 -c base64.c -o base64.o /opt/csw/include/curl/curlrules.h, line 144: zero or negative subscript This error indicates that the compiler (cc with flags -xc99 -m64, etc.) sees the size of the 'long' data type in C is different from what was seen when libcurl was configured, built and installed. So basically the compiler and/or the compiler flags were different. How was libcurl installed - from source or from a pre-built binary ? What compiler and flags were used? The header is from a prebuilt binary (from OpenCSW). That is built with gcc and not the Sun compiler. And curlbuild.h says /* Allow 32 and 64 bit headers to coexist */ #if defined __amd64 || defined __x86_64 || defined __sparcv9 #include curlbuild-64.h #else #include curlbuild-32.h #endif which AFAIK are gcc and not Sun defines. You could try adding -D__sparcv9 to the CPPFLAGS, or compile RCurl with OpenCSW's gcc build (but 64-bit gcc is another can of worms). I've pointed out to Jun Zhang several times that 64-bit Sparc Solaris is really pushing it, and 32-bit R on Sparc Solaris has been much more successful. Given that x86_64 boxes (Solaris or Linux) are so much faster at computation than Sparc ones, I don't see the point of building 64-bit Sparc Solaris R -- if 32-bit R is not enough you need a faster machine. D. base64.c, line 25: warning: assignment type mismatch: pointer to const char = pointer to unsigned char base64.c, line 39: warning: argument #1 is incompatible with prototype: prototype: pointer to const char : /apps/sparcv9/R-2.12.0/lib/R/include/Rinternals.h, line 1042 argument : pointer to unsigned char base64.c, line 60: warning: assignment type mismatch: pointer to const char = pointer to unsigned char cc: acomp failed for base64.c make: *** [base64.o] Error 2 ERROR: compilation failed for package 'RCurl' * removing '/apps/sparcv9/R-2.12.0/lib/R/library/RCurl' The downloaded packages are in '/tmp/Rtmpo67mNX/downloaded_packages' Updating HTML index of packages in '.Library' Warning message: In install.packages(RCurl) : installation of package 'RCurl' had non-zero exit status What is the problem? Jun [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics,
Re: [Rd] 0.5 != integrate(dnorm,0,20000) = 0
On Mon, 6 Dec 2010, Spencer Graves wrote: Hello: The example integrate(dnorm,0,2) says it fails on many systems. I just got 0 from it, when I should have gotten either an error or something close to 0.5. I got this with R 2.12.0 under both Windows Vista_x64 and Linux (Fedora 13); see the results from Windows below. I thought you might want to know. Well, isn't that exactly what the help page says happens? That example is part of a section entitled ## integrate can fail if misused and is part of the illustration of If the function is approximately constant (in particular, zero) over nearly all its range it is possible that the result and error estimate may be seriously wrong. Thanks for all your work in creating and maintaining R. Best Wishes, Spencer Graves ### integrate(dnorm,0,2) ## fails on many systems 0 with absolute error 0 sessionInfo() R version 2.12.0 (2010-10-15) Platform: i386-pc-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
