[R] R badly lags matlab on performance?

[luke at stat.uiowa.edu]

On Sat, 3 Jan 2009, Duncan Murdoch wrote:

> On 03/01/2009 1:37 PM, Ajay Shah wrote:
>>> As for jit and Ra, that was immediate reaction too but I found that jit 
>>> does
>>> not help on your example.  But I concur fully with what Ben said --- use 
>>> the
>>> tool that is appropriate for the task at hand.  If your task is running 
>>> for
>>> loops, Matlab does it faster and you have Matlab, well then you should by 
>>> all
>>> means use Matlab.
>> 
>> A good chunk of statistical computation involves loops. We are all
>> happy R users. I was surprised to see that we are so far from matlab
>> in the crucial dimension of performance.
>> 
>
> I don't know Matlab, but I think the thing that is slowing R down here is its 
> generality.  When you write
>
> a[i] <- a[i] + 1
>
> in R, it could potentially change the meaning of a, [, <-, and + on each step 
> through the loop, so R looks them up again each time.  I would guess that's 
> not possible in Matlab, or perhaps Matlab has an optimizer that can recognize 
> that in the context where the loop is being evaluated, those changes are 
> known not to happen.

R's interpreter is fairly slow due in large part to the allocation of
argument lists and the cost of lookups of variables, including ones
like [<- that are assembled and looked up as strings on every call.

> It *would* be possible to write such an optimizer for 
> R, and Luke Tierney's byte code compiler-in-progress might incorporate such a 
> thing.

The current byte code compiler available from my web site speeds this
(highly artificial) example by about a factor of 4.  The experimental
byte code engine I am currently working on (and that can't yet do much
more than an example like this) speeds this up by a factor of
80. Whether that level of improvement (for toy examples like this)
will remain once the engine is more complete and whether a reasonable
compiler can optimize down to the assembly code I used remain to be
seen.

> For the difference in timing on the vectorized versions, I'd guess that 
> Matlab uses a better compiler than gcc.  It's also likely that R incorporates 
> some unnecessary testing even in a case like this, because it's easier to 
> maintain code that is obviously sane than it is to maintain code that may not 
> be.  R has a budget which is likely several orders of magnitude smaller than 
> Mathworks has, so it makes sense to target our resources at more important 
> issues than making fast things run a bit faster.

Another possibility is optimization setting tht may be higher and/or
more processor specific than those used by R.

We do handle the case where both arguments to + are scalar (i.e. of
length 1) separately but I don't recall if we do so for the
vector/scalar case also -- I suspect not as that would make the code
less maintainable for not a very substantial gain.

luke

> Duncan Murdoch
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>

-- 
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu