[R-SIG-Mac] Using GCC4/GFORTRAN with R (and R.app)

[Jan de Leeuw]

On Dec 1, 2005, at 14:27 , Simon Urbanek wrote:

> Jan, if you have a spare minute, can you run some benchmarks of  
> your gcc4-optimized R (preferably involving mostly Fortran code vs  
> just C) against the CRAN binary? That would be quite helpful in  
> assessing the current speed benefits...


This is on a quad (2 x 2 x 2.5 Ghz) G5 with OS X 10.4.4 and 2GB of RAM.
I used

hilbert<-function(n) 1/(outer(seq(n),seq(n),"+")-1)
print("hilbert n=500")
print(system.time(eigen(hilbert(500))))
print(system.time(eigen(hilbert(500))))
print(system.time(eigen(hilbert(500))))
print("hilbert n=1000")
print(system.time(eigen(hilbert(1000))))
print(system.time(eigen(hilbert(1000))))
print(system.time(eigen(hilbert(1000))))
print("sort n=6")
print(system.time(sort(rnorm(10^6))))
print(system.time(sort(rnorm(10^6))))
print(system.time(sort(rnorm(10^6))))
print("sort n=7")
print(system.time(sort(rnorm(10^7))))
print(system.time(sort(rnorm(10^7))))
print(system.time(sort(rnorm(10^7))))
# loess
loess.me<-function(n) {
print(paste("loess n=",as.character(n),sep=""))
for (i in 1:5) {
	x<-rnorm(10^n); y<-rnorm(10^n); z<-rnorm(10^n)
	print(system.time(loess(z~x+y)))
	}
}
loess.me(3)
loess.me(4)

First for R-2.3.0 r36557, optimized for G5, compiled with gcc and  
gfortran 4.0.1 (Apple build 5305)

[1] "hilbert n=500"
[1] 0.50 0.16 0.56 0.00 0.00
[1] 0.43 0.16 0.49 0.00 0.00
[1] 0.41 0.15 0.48 0.00 0.00
[1] "hilbert n=1000"
[1] 2.71 0.74 2.79 0.00 0.00
[1] 2.34 0.74 2.43 0.00 0.00
[1] 2.36 0.80 2.53 0.00 0.00
[1] "sort n=6"
[1] 0.64 0.03 0.67 0.00 0.00
[1] 0.64 0.03 0.68 0.00 0.00
[1] 0.64 0.03 0.67 0.00 0.00
[1] "sort n=7"
[1] 7.85 0.30 8.15 0.00 0.00
[1] 7.80 0.28 8.08 0.00 0.00
[1] 7.81 0.30 8.11 0.00 0.00
[1] "loess n=3"
[1] 0.07 0.01 0.07 0.00 0.00
[1] 0.06 0.00 0.07 0.00 0.00
[1] 0.07 0.00 0.06 0.00 0.00
[1] 0.06 0.00 0.07 0.00 0.00
[1] 0.07 0.00 0.06 0.00 0.00
[1] "loess n=4"
[1] 4.50 0.06 4.56 0.00 0.00
[1] 4.63 0.05 4.69 0.00 0.00
[1] 4.58 0.05 4.63 0.00 0.00
[1] 4.63 0.04 4.67 0.00 0.00
[1] 4.66 0.04 4.69 0.00 0.00

Then for the CRAN R-2.2.0 r35749 using gcc and g77 3.3

[1] "hilbert n=500"
[1] 0.51 0.19 0.63 0.00 0.00
[1] 0.44 0.16 0.51 0.00 0.00
[1] 0.42 0.15 0.48 0.00 0.00
[1] "hilbert n=1000"
[1] 2.72 0.74 2.79 0.00 0.00
[1] 2.37 0.72 2.44 0.00 0.00
[1] 2.37 0.74 2.45 0.00 0.00
[1] "sort n=6"
[1] 0.65 0.03 0.69 0.00 0.00
[1] 0.64 0.03 0.67 0.00 0.00
[1] 0.65 0.02 0.68 0.00 0.00
[1] "sort n=7"
[1] 7.88 0.34 8.23 0.00 0.00
[1] 7.84 0.33 8.20 0.00 0.00
[1] 7.86 0.33 8.22 0.00 0.00
[1] "loess n=3"
[1] 0.07 0.00 0.10 0.00 0.00
[1] 0.07 0.00 0.07 0.00 0.00
[1] 0.06 0.00 0.07 0.00 0.00
[1] 0.07 0.01 0.07 0.00 0.00
[1] 0.07 0.00 0.07 0.00 0.00
[1] "loess n=4"
[1] 4.79 0.04 4.83 0.00 0.00
[1] 4.83 0.05 4.90 0.00 0.00
[1] 4.74 0.04 4.77 0.00 0.00
[1] 4.89 0.05 4.94 0.00 0.00
[1] 4.79 0.05 4.84 0.00 0.00

hilbert() will spend most of its time in vecLib, so there is  
obviously very little
difference. For loess we see a speedup of about 5% -- not very  
impressive. Certainly not
since it comes from both a compiler difference and a difference in  
optimization flags. But
since there is no use of SMP and no single precision floating point,  
we can't expect
too much from the optimization anyway. Moral: if you want to run your  
R faster, upgrade
your CPU.

===
Jan de Leeuw; Distinguished Professor and Chair, UCLA Department of  
Statistics;
Editor: Journal of Multivariate Analysis, Journal of Statistical  
Software
US mail: 8130 Math Sciences Bldg, Box 951554, Los Angeles, CA 90095-1554
phone (310)-825-9550;  fax (310)-206-5658;  email: deleeuw at stat.ucla.edu
.mac: jdeleeuw ++++++  aim: deleeuwjan ++++++ skype: j_deleeuw
homepages: http://gifi.stat.ucla.edu ++++++ http://www.cuddyvalley.org
   
------------------------------------------------------------------------ 
-------------------------
           No matter where you go, there you are. --- Buckaroo Banzai
                    http://gifi.stat.ucla.edu/sounds/nomatter.au