[R] R on 64-bit Linux machine

Peter Dalgaard p.dalgaard at biostat.ku.dk
Sat Nov 13 16:29:52 CET 2004


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




More information about the R-help mailing list