Multi-thread R processes performance on 8-core Mac-Pro

Everyone,

I am running R 2.4.1 on the new 8-core Mac Pro with the parSapply
function from the Snow package. Tests using 2,4, and 8 threads with
makeCluster() yield somewhat disappointing results. The 4 thread process
is fastest. With 8 threads, all the cores max out at about 70% power,
and even then it is slower than the 4 thread process which maxes out the
4 threads at about 90-95%. This suggests the additional 4 cores on the
Mac Pro do not improve performance in an embarrassingly parallel R/Snow
environment...

The function I tested in parSapply runs a regression (a call to "lm"). I
am using Snow/rpvm package combination. There is no issue of limited
memory. There are over 3 gigs of free RAM in the tests.

Does anyone have suggestions as how to get more power out of a
multi-core Mac Pro machine and/or have 4-core/8-core R multi-thread
computing performance benchmarks/experiences to share?

I am running R 2.4.1 on the new 8-core Mac Pro with the parSapply 
function from the Snow package. Tests using 2,4, and 8 threads with 
makeCluster() yield somewhat disappointing results. The 4 thread process 
is fastest. With 8 threads, all the cores max out at about 70% power, 
and even then it is slower than the 4 thread process which maxes out the 
4 threads at about 90-95%. This suggests the additional 4 cores on the 
Mac Pro do not improve performance in an embarrassingly parallel R/Snow 
environment...

The function I tested in parSapply runs a regression (a call to "lm"). I 
am using Snow/rpvm package combination. There is no issue of limited 
memory. There are over 3 gigs of free RAM in the tests.

I am running R 2.4.1 on the new 8-core Mac Pro with the parSapply
function from the Snow package. Tests using 2,4, and 8 threads with
makeCluster() yield somewhat disappointing results. The 4 thread  
process
is fastest. With 8 threads, all the cores max out at about 70% power,
and even then it is slower than the 4 thread process which maxes  
out the
4 threads at about 90-95%. This suggests the additional 4 cores on  
the
Mac Pro do not improve performance in an embarrassingly parallel R/ 
Snow
environment...

The function I tested in parSapply runs a regression (a call to  
"lm"). I
am using Snow/rpvm package combination. There is no issue of limited
memory. There are over 3 gigs of free RAM in the tests.

There has been some discussion (elsewhere) of the mac pro  
motherboard's inability to keep all eight cores supplied with data  
from memory at an adequate rate.

Your processor cores may simply be starved for data.  The amount of  
memory available doesn't matter, much, if there's no IO bandwidth  
left between the CPUs and the DIMMs....................

Thank you to everyone who contributed to understanding the multi-core
problem better. I took Elijah's advice and purchased a Leopard
pre-release DVD and will post performance results here when it arrives
and if the results are interesting (should be!). I'll also post the
result from Simon's BLAS test in a few hours.

In the meantime, there is a speed problem to solve. Appreciate advice
anyone may have on potential approaches for speeding up the following
function. Based on previous comments, fewer calls to memory may be
important...

results <- function(x){
fit <- lm(Y ~
get(cmb[x,1])+get(cmb[x,2])+get(cmb[x,3])+get(cmb[x,4])+get(cmb[x,5]),
data=data1)
list(R2=summary(fit)$adj.r.squared) }

This call to lm function is nested in a parSapply function that iterates
down the rows of the "cmb" matrix. Each row of cmb has, in the example
above, 5 character values (such as "var1", "var2",..."var5")
corresponding to variable names in the "data1" dataframe. The function
iterates down the rows, generating regressions, each with a different
combination of variables. (x just goes from 1 to whatever number of rows
are in cmb.) Finally the function delivers the R2 for each combination.

Any speed-up ideas?

David

On 4/19/07, Marra, David <David.Marra at atkearney.com> wrote:

Thank you to everyone who contributed to understanding the multi-core
problem better. I took Elijah's advice and purchased a Leopard
pre-release DVD and will post performance results here when it arrives
and if the results are interesting (should be!). I'll also post the
result from Simon's BLAS test in a few hours.

In the meantime, there is a speed problem to solve. Appreciate advice
anyone may have on potential approaches for speeding up the following
function. Based on previous comments, fewer calls to memory may be
important...

results <- function(x){
fit <- lm(Y ~
get(cmb[x,1])+get(cmb[x,2])+get(cmb[x,3])+get(cmb[x,4])+get(cmb[x,5]),
data=data1)
list(R2=summary(fit)$adj.r.squared) }

This call to lm function is nested in a parSapply function that iterates
down the rows of the "cmb" matrix. Each row of cmb has, in the example
above, 5 character values (such as "var1", "var2",..."var5")
corresponding to variable names in the "data1" dataframe. The function
iterates down the rows, generating regressions, each with a different
combination of variables. (x just goes from 1 to whatever number of rows
are in cmb.) Finally the function delivers the R2 for each combination.

Can you be more specific about what x is here?  What you write makes
it sound as if x is a single row but you wouldn't be able to do a
linear model fit on a single row.  It must be more than one row.

The immediate way to speed things up is to use lm.fit directly instead
of going through lm.  The lm function is a convenience function to
take a formula/data representation of a linear model along with
several optional arguments and create the model matrices.  In this
case you can create the model matrix for all the rows in a single
call, provided that it fits into memory, then farm out the individual
fits.  Also, the call to summary does a lot more that calculate an
adjusted R-squared.  You can calculate this single statistic directly
from the dimensions of the problem and the "effects" component of the
lm fit.

Any speed-up ideas?

David