Dear R Developers, A recommendation for future development. It would help if R scripts could be compiled into an executable, or a library. Speed is the main issue (I run a large scale monte carlo in R which is very slow). However, it would also make it easier to link R into other applications, easier at least than the COM infrastructure under Windows. Finally, it would make it much easier to farm R apps: rather than distributing all of R and necessary libraries onto each client, and making sure each client is always up to date as libraries for a specific script change, it might be easier just to distribute a simple executable across all nodes. Regards, Tolga =============================================================================Please access the attached hyperlink for an important electronic communications disclaimer: http://www.csfb.com/legal_terms/disclaimer_external_email.shtml
Uzuner, Tolga wrote:> Dear R Developers,> It would help if R scripts could be compiled into an executable, or a > library.Are you sure it would help? If you do a big matrix operation in R it runs at the speed of the underlying C code. It wont get much faster. Profile your code, find out where the time is being spent, then optimise _that_.> Speed is the main issue (I run a large scale monte carlo in > R which is very slow).The reason its very slow is not because its 'in R' but because it is a 'large scale monte carlo'. What was a 'large scale' monte-carlo ten years ago runs in no time today. 'large scale' == 'slow' almost by definition. Unless you've done comparisons with the same code written in some other language.> However, it would also make it easier to link > R into other applications, easier at least than the COM > infrastructure under Windows.R can be called from C, and there are application links to Python, Perl, Java... Easy enough.> Finally, it would make it much easier to farm R apps: rather than > distributing all of R and necessary libraries onto each client, and > making sure each client is always up to date as libraries for a > specific script change, it might be easier just to distribute a > simple executable across all nodes.Keeping a bunch of clients up to date is as easy as a quick scripted rsync command, or completely transparent if you have a shared /usr/local filesystem (Unix). There is some work going on to produce an R compiler, but I dont think these are the reasons. Baz
On Jul 4, 2005, at 6:31 AM, Uzuner, Tolga wrote:> Dear R Developers, > > A recommendation for future development. > > It would help if R scripts could be compiled into an executable, or > a library. Speed is the main issue (I run a large scale monte carlo > in R which is very slow). However, it would also make it easier to > link R into other applications, easier at least than the COM > infrastructure under Windows. >1. Easier said than done. Much much easier said than done. 2. Move the bottleneck bits to C. Alternatively, I've found that for MCMC at least, employing R's lexical scoping features and using sapply to do the iteration can vastly improve performance (as well as improving your code's readability). If you're doing pure monte carlo the lexical scoping may not be of much help, but using something like sapply often helps. R is not C/C++/Java/Fortran and should not be programmed as such. 3. Look at the RDCOM stuff at www.omegahat.org.> Finally, it would make it much easier to farm R apps: rather than > distributing all of R and necessary libraries onto each client, and > making sure each client is always up to date as libraries for a > specific script change, it might be easier just to distribute a > simple executable across all nodes.Put all of that into an R package and then put the package into a local library location (i.e. one in your home directory). Unless something is odd, your home directory should be distributed to all nodes. Unless you're running a Windows cluster, at which point I have to ask... why?> > Regards, > Tolga > > > ====================================================================== > =======> Please access the attached hyperlink for an important electronic > communications disclaimer: > > http://www.csfb.com/legal_terms/disclaimer_external_email.shtml > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >--- Byron Ellis (ellis at stat.harvard.edu) "Oook" -- The Librarian