Don't underestimate the importance of the choice of the algorithm you use. That often makes a huge difference. Also, vectorization is key in R, and when you use that you're really up there among the top performing languages. Here is an example from the official R wiki illustrating my points:
http://rwiki.sciviews.org/doku.php?id=tips:programming:code_optim2 My rule of thumb is: Any piece of code can be made twice as fast. /Henrik On Fri, Sep 10, 2010 at 6:06 AM, Prof. John C Nash <nas...@uottawa.ca> wrote: > Dirk E. has properly focussed the discussion on measurement rather than > opinion. I'll add the issue of the human time taken to convert, and more > importantly debug, interfaced code. That too could be measured, but we > rarely see human hours to code/debug/test reported. > > Moreover, I'll mention the cat among the pigeons of Rcgmin, which I wrote to > allow me to play with an optimization code more easily to discover where the > algorithm might be improved. The resulting package on some problems > outperforms C equivalents. Now the code is quite vectorized, but this has > still been a very nice surprise. In fact, I've decided to avoid playing > around with the interfaces if I can run things well-enough entirely in R. > > JN > > ______________________________________________ > R-help@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. > ______________________________________________ R-help@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.
