[R-sig-Finance] Backtesting speed
eric larson
eric at ehlarson.com
Thu Jul 20 00:06:30 CEST 2006
roger bos wrote:
> Yeah reading the link above, I would summarize it as this: If someone is
> good at/and likes C/C++, you will never be able to convince them that an
> interpretted language is as good. Most proponents of interpretted languages
> just figure the processor speed and memory improvements will allow them to
> carry on without using compilers. When I profile my R code, the vast
> majority of the time is usually in read.table and write.table, so I figure
> there is not much I can do to improve my code. While using Perl & C & R
> together could bring some speed imporovement, there is also a downside to
> learning and maintaining code in different langues and putting all the
> pieces together.
>
> But then again, I work with monthly data, so its not really a concern of
> mine. Most hedge funds that work with tick data use Perl to process the
> data and then maybe R to analyze it. Basically, the volume is too great to
> do in R. Of course linking to a database to a nice plus in R, I don't know
> if Perl can do that.
>
Actually Perl has excellent database connectivity. The DBA's I work with
tend to
use Perl more than anything else to write DB maintenance and data
transformation
tools because the combination of Perl's db connectivity and text
manipulation
capabilities is very hard to beat.
As far as interpreted vs. compiled code the gap is narrowing every day.
C doesn't map
directly to machine instructions as in the past as CPUs become more
sophisticated,
and languages like Java are using techniques like run-time optimization
that are not
available to statically compiled languages.
More information about the R-SIG-Finance
mailing list