From djsamperi at gmail.com  Sat Mar 10 15:41:36 2012
From: djsamperi at gmail.com (Dominick Samperi)
Date: Sat, 10 Mar 2012 09:41:36 -0500
Subject: [Rd] On R performance
In-Reply-To: <CALLn38Pmn8ZTYCc17R0QVjjLsQzo0jJOLinjZFzkhRhvDRVWwg@mail.gmail.com>
References: <CALLn38PjixLnWw=uBwB-5QYDEa=tLNahuSnap_A_oQQ_=qS4TA@mail.gmail.com>
	<CADUbQ5jZEM1bV+xBdjgF8HxOTM7SGy3zkvefZZ4nKWQGVwQNtw@mail.gmail.com>
	<CALLn38Pmn8ZTYCc17R0QVjjLsQzo0jJOLinjZFzkhRhvDRVWwg@mail.gmail.com>
Message-ID: <CADUbQ5iN7V78+Eo1fQRRPGeoAFt991sDjdM590U3xtr-PF7YdA@mail.gmail.com>

On Fri, Mar 9, 2012 at 11:39 AM, Justin Talbot <jtalbot at cs.stanford.edu> wrote:
>>
>> Isn't R much like Lisp under the covers? Afterall, it evolved from Scheme.
>> Hasn't there been a great deal of work done on optimizing Lisp over the
>> last 30 years? This suggests that instead of dropping the R/S semantics
>> and moving to another language like Julia, the proposals of Ross Ihaka
>> and Duncan Temple Lang could be followed to provide the familiar
>> R/S syntax on top of an optimized Lisp engine.
>>
>
> I think R started off as a Lisp-like language, but since adopting S
> semantics, it has diverged quite a ways. I think it's better to think
> of R as a combination of two languages: a dynamically-typed high-level
> language, much like Javascript or Lua, and an array language, like
> APL. I think those are the right places to be looking to see how to
> make R fast. Fortunately, all three of those languages have had a lot
> of performance work done already that R could just steal from
> wholesale.

Thanks for the clarification Justin. What about the S4 classes
and methods? The design resembles CLOS, and currently this
is interpreted R code. Have you addressed performance issues
associated with this? What relative impact does this have compared
with other optimizations like vectorization?

Thanks,
Dominick

>> Another possibility is to implement R/S on top of an optimized virtual
>> machine like the JVM, LLVM, etc.
>>
>
> I like this in theory. But in practice, I'm not sure how well it would
> work for R. JVM implementations of dynamic languages, like JRuby and
> Jython run marginally faster (30-40%) than their C interpreters. You
> do get the Java ecosystem, which is nice, but the performance
> improvements probably aren't enough to make it worthwhile. And, of
> course, R already has a pretty good Java connection story.
>
> LLVM is a better option; I know there's another group out there
> looking at R on LLVM. But I'll just note that the really high
> performance dynamic languages (e.g. Google's V8 implementation of
> Javascript and Mike Pall's LuaJIT) are hand-rolled JITs. LLVM-based
> implementations of dynamic languages, like Unladen Swallow, have not
> been particularly successful. It remains to be seen how well R would
> map to LLVM.
>
> Justin



[Rd] On R performance
Dominick Samperi