An embedded and charset-unspecified text was scrubbed... Name: not available Url: https://stat.ethz.ch/pipermail/r-help/attachments/20041112/b82c6ba0/attachment.pl
R on 64-bit Linux machine
9 messages · Vadim Ogranovich, Roger D. Peng, Peter Dalgaard +1 more
I've built (and routinely use) 64 bit R on the following platforms: Red Hat Enterprise Linux AS release 3 (AMD Opteron 848) Fedora Core 2 x86_64 (AMD Athlon 64 3800+) SuSE SLES 8 (AMD Opteron 248) One problem that has come up is that if you want to link R with ATLAS, you need to build shared ATLAS libraries (rather than static). This requires some modifications to the configuation files for ATLAS. But my experience shows that R itself builds out of the box on these systems. -roger
Vadim Ogranovich wrote:
Hi, We are planning to buy a 64-bit Linux machine which will mainly run R. There was an interesting thread on 64-bits on r-help back in April that basically confirmed that the 64-bit R is fine as long as the length of an atomic object is less than 2^31 - 1. My specific question is on which 64-bit Linux distros (SUSE or RedHat) and processors R is *known* to build out-of-box and run well. Ease of maintenance is essential here. We have RedHat 7.3 on other (32-bit) machines and would try not to proliferate the OS-s. Your information will be highly appreciated, Thanks, Vadim [[alternative HTML version deleted]]
______________________________________________ R-help at stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
Roger D. Peng http://www.biostat.jhsph.edu/~rpeng/
On Fri, 12 Nov 2004, Vadim Ogranovich wrote:
Hi, We are planning to buy a 64-bit Linux machine which will mainly run R. There was an interesting thread on 64-bits on r-help back in April that basically confirmed that the 64-bit R is fine as long as the length of an atomic object is less than 2^31 - 1.
That's an R limitation, not a 64-bit version one.
My specific question is on which 64-bit Linux distros (SUSE or RedHat) and processors R is *known* to build out-of-box and run well. Ease of maintenance is essential here. We have RedHat 7.3 on other (32-bit) machines and would try not to proliferate the OS-s.
Not RHEL 3: we sent that back for a refund and its compilers are too old to work well on AMD64. Fedora Core 3 is fine on AMD64, and is what I would recommend. We also run SuSe 9.1, but for people used to RH, Fedora is more familiar. CRAN will have 64-bit RPMs for x86_64 FC3 come R 2.0.1 (released on Monday)
Brian D. Ripley, ripley at 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, UK Fax: +44 1865 272595
On Fri, 12 Nov 2004, Roger D. Peng wrote:
I've built (and routinely use) 64 bit R on the following platforms: Red Hat Enterprise Linux AS release 3 (AMD Opteron 848) Fedora Core 2 x86_64 (AMD Athlon 64 3800+) SuSE SLES 8 (AMD Opteron 248) One problem that has come up is that if you want to link R with ATLAS, you need to build shared ATLAS libraries (rather than static). This requires some modifications to the configuation files for ATLAS. But my experience shows that R itself builds out of the box on these systems.
However, you will almost certainly get better performance out of the Goto BLAS implementations, and they are shared (and easy to use, much more so than ATLAS).
Brian D. Ripley, ripley at 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, UK Fax: +44 1865 272595
"Roger D. Peng" <rpeng at jhsph.edu> writes:
I've built (and routinely use) 64 bit R on the following platforms: Red Hat Enterprise Linux AS release 3 (AMD Opteron 848) Fedora Core 2 x86_64 (AMD Athlon 64 3800+) SuSE SLES 8 (AMD Opteron 248)
Nice to know about the Enterprise variants. FC2/3 and SUSE 9.1 are known good too (did anyone check 9.2 yet?).
One problem that has come up is that if you want to link R with ATLAS, you need to build shared ATLAS libraries (rather than static). This requires some modifications to the configuation files for ATLAS. But my experience shows that R itself builds out of the box on these systems.
Actually, you can just go through configuration and add -fPIC to the compiler flags. Then at the end, run ld --shared --whole-archive -o libatlas.so libatlas.a etc. [If you don't accept architectural defaults (as you probably shouldn't), the compile/optimize is going to take a while. I wouldn't know how big the difference is, but -fPIC _will_ force code differences.]
-roger Vadim Ogranovich wrote:
Hi, We are planning to buy a 64-bit Linux machine which will mainly run R. There was an interesting thread on 64-bits on r-help back in April that basically confirmed that the 64-bit R is fine as long as the length of an atomic object is less than 2^31 - 1. My specific question is on which 64-bit Linux distros (SUSE or RedHat) and processors R is *known* to build out-of-box and run well. Ease of maintenance is essential here. We have RedHat 7.3 on other (32-bit) machines and would try not to proliferate the OS-s. Your information will be highly appreciated, Thanks, Vadim [[alternative HTML version deleted]]
______________________________________________ R-help at stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
-- Roger D. Peng http://www.biostat.jhsph.edu/~rpeng/
______________________________________________ R-help at stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
ATLAS, you need to build shared ATLAS libraries (rather than static). This requires some modifications to the configuation files for ATLAS. But my experience shows that R itself builds out of the box on these systems.
However, you will almost certainly get better performance out of the Goto BLAS implementations, and they are shared (and easy to use, much more so than ATLAS).
I actually have different experience in the multithreaded case, at least with my favourite "benchmark suite": inversion of a large matrix. I'd do some timings, but I have this ATLAS compile running just now...
O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
Peter Dalgaard <p.dalgaard at biostat.ku.dk> writes:
Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
ATLAS, you need to build shared ATLAS libraries (rather than static). This requires some modifications to the configuation files for ATLAS. But my experience shows that R itself builds out of the box on these systems.
However, you will almost certainly get better performance out of the Goto BLAS implementations, and they are shared (and easy to use, much more so than ATLAS).
I actually have different experience in the multithreaded case, at least with my favourite "benchmark suite": inversion of a large matrix. I'd do some timings, but I have this ATLAS compile running just now...
Specifically, here's what I got: pd at linux:~/r-devel> echo 'set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))' | BUILD/bin/R -q --vanilla
set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))
[1] 218.00 1.27 219.62 0.00 0.00
pd at linux:~/r-devel> echo 'set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))' | BUILD-GOTO/bin/R -q --vanilla
set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))
[1] 29.12 1.39 32.21 0.00 0.00
pd at linux:~/r-devel> echo 'set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))' | BUILD-ATLAS/bin/R -q --vanilla
set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))
[1] 3.24 1.31 21.45 31.75 0.24
So ATLAS is faster than GOTO by about 10 seconds. It is a bit odd that the GOTO timings don't seem to include any subprocess time but it should be the threaded library libgoto_opt64p-r0.93.so (I know; there's a 0.96 now, will upgrade).
O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
On Sat, 13 Nov 2004, Peter Dalgaard wrote:
Peter Dalgaard <p.dalgaard at biostat.ku.dk> writes:
Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
ATLAS, you need to build shared ATLAS libraries (rather than static). This requires some modifications to the configuation files for ATLAS. But my experience shows that R itself builds out of the box on these systems.
However, you will almost certainly get better performance out of the Goto BLAS implementations, and they are shared (and easy to use, much more so than ATLAS).
I actually have different experience in the multithreaded case, at least with my favourite "benchmark suite": inversion of a large matrix. I'd do some timings, but I have this ATLAS compile running just now...
Specifically, here's what I got: pd at linux:~/r-devel> echo 'set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))' | BUILD/bin/R -q --vanilla
set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))
[1] 218.00 1.27 219.62 0.00 0.00
pd at linux:~/r-devel> echo 'set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))' | BUILD-GOTO/bin/R -q --vanilla
set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))
[1] 29.12 1.39 32.21 0.00 0.00
pd at linux:~/r-devel> echo 'set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))' | BUILD-ATLAS/bin/R -q --vanilla
set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))
[1] 3.24 1.31 21.45 31.75 0.24
So ATLAS is faster than GOTO by about 10 seconds. It is a bit odd that
Not on total CPU time (it's slower by about the margin I would expect), only on elapsed time.
the GOTO timings don't seem to include any subprocess time but it should be the threaded library libgoto_opt64p-r0.93.so (I know; there's a 0.96 now, will upgrade).
I get (on a dual Opteron 248 with 0.96-2) [1] 20.59 1.01 19.10 0.00 0.00 which note is using more than 100% CPU time. Are you sure you are using multiple threads with Goto? I have never built a threaded ATLAS for that machine, as in our environment people are normally running multiple jobs and it is total CPU time that counts.
Brian D. Ripley, ripley at 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, UK Fax: +44 1865 272595
Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
pd at linux:~/r-devel> echo 'set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))' | BUILD-GOTO/bin/R -q --vanilla
set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))
[1] 29.12 1.39 32.21 0.00 0.00
pd at linux:~/r-devel> echo 'set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))' | BUILD-ATLAS/bin/R -q --vanilla
set.seed(1);M<-matrix(rnorm(9e6),3e3);system.time(solve(M))
[1] 3.24 1.31 21.45 31.75 0.24
So ATLAS is faster than GOTO by about 10 seconds. It is a bit odd that
Not on total CPU time (it's slower by about the margin I would expect), only on elapsed time.
True, but there's always a penalty on multithreading nontrivial code, so to minimize total time, use only one CPU...
the GOTO timings don't seem to include any subprocess time but it should be the threaded library libgoto_opt64p-r0.93.so (I know; there's a 0.96 now, will upgrade).
I get (on a dual Opteron 248 with 0.96-2) [1] 20.59 1.01 19.10 0.00 0.00 which note is using more than 100% CPU time. Are you sure you are using multiple threads with Goto?
Fairly sure... I got (dual Opteron 240, now also 0.96-2) [1] 29.21 1.50 30.97 0.00 0.00 so less than 100% but the timing ratio seems fairly consistent with the clock speeds (1.4 GHz vs. 2.2 GHz).
O__ ---- Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907