Dear R makers and users.
I summarize answers to my question. Thanks
for your help.
The conclusion seems to be
that, in terms of performance with large datasets,
Matlab=Octave > R > Splus5.1 > Splus5.0
but Matlab/Octave lack many of the stat
functions of R/S, and,
R does not have as many time-series functions
as S+ (but see last message to r-announce by adrian.trapletti at wu-wien.ac.at
on new time series package available).
SUMMARY:
alobo at ija.csic.es
> Dear R makers and users:
>
> After reading the FAQ and the comments on the
> comparison between R and S, I still have an important
> (at least for me) question: How is R compared
> to the new version of Splus 5.0 (for unix including Linux)?
>
> I must pay particular atention to the efficiency
> with large datasets and, more generally speaking,
> to the efficiency with memory management.
jsekhon at fas.harvard.edu
1. I've found Splus 5.1 for LINUX to have far worse memory management than
Splus 3.x. There are several key memory bugs listed in the release notes.
One being that Splus doesn't recover memory well (at all?) in for loops.
2. I've found R to be much faster than 5.1 in handling loops.
3. Also, R seems to be much faster when being called from C (using
call_R) than Splus.
4. Splus 5.1 seems to handle large data sets better---if you don't do much
with them.
###########################################################################
thomas at biostat.washington.edu
1. There is not a lot known about the precise circumstances that affect the
relative performance of R and S-PLUS.
2. Tests based on code from "Modern
Applied Statistics with S-PLUS" by Venables and Ripley show R as somewhat
slower.
3. A number of people (including me) have found R to be substantially
faster on specific simulation problems, sometimes involving large datasets
and sometimes not. This is by no means universally true, and we don't have
good rules for predicting when R is faster. Basically, R copies things
less often but doesn't recover memory particularly efficiently.
4. If your object size is a substantial fraction of available memory R will
not perform well.
5. S-PLUS may well be better, but it won't be very good
either.
6. There are a number of planned changes to the internals of R
that should provide some speedup (better garbage collection, hashing of all
environments), but we don't know how much.
7. If there are strong cost constraints and memory size is an important
barrier it may be worth using R and buying extra memory, which is
comparatively cheap for Intel machines.
#############################################################################
ripley at stats.ox.ac.uk
1. The memory management of Splus 5.1 is much better than 5.0.
It is likely that 5.1 has not yet reached European distributors,
but it is imminent.
2. I would say this has much more to do with programming well than the
choice between S-PLUS and R. I have happily processed time-series of
MRI images on my (192Mb RAM) laptop in all of S-PLUS 4.5, 5.1 and
pre-R-0.64.2. These are large (ca 50Mb per dataset). What `well'
means differs between these systems.
#####################################################################
ammann at utdallas.edu
1. I also work with remote sensing satellite data, mainly Landsat
and AVIRIS.
2. I have found Octave to be very useful
since it includes functions for reading unsigned integer data
sets, and its handling of these very large data sets seems to be
more efficient than R or S+, at least for standard matrix
functions like BLAS, QR, and SVD
3. Various clustering algorithms and statistical models beyond the
standard least squares would be better handled using either R or
S+.
4. I taught a class last year on
image processing for remote sensing data and had the students
use Octave for Linux in my computer lab to do the processing
and they were able to progress rather successfully.
Dr. Agustin Lobo
Instituto de Ciencias de la Tierra (CSIC)
Lluis Sole Sabaris s/n
08028 Barcelona SPAIN
tel 34 93409 5410
fax 34 93411 0012
alobo at ija.csic.es
http://pangea.ija.csic.es/alobo
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-help-request at
stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
