fisher.test seems to use the .C calling convention in a couple of
different places.
for example:
tmp <- .C("fisher_sim", as.integer(nr), as.integer(nc),
as.integer(sr), as.integer(sc), as.integer(n),
as.integer(B), integer(nr * nc), double(n + 1),
integer(nc), results = double(B), PACKAGE =
"stats")$results
perhaps some R experts on the list can tell us whether there is
significant overhead to .C vs .Call.
Does .C really duplicate its arguments? What does RObjToCPtr do?
(line 1682.. in dotcode.c)
/* Convert the arguments for use in foreign */
/* function calls. Note that we copy twice */
/* once here, on the way into the call, and */
/* once below on the way out. */
cargs = (void**)R_alloc(nargs, sizeof(void*));
nargs = 0;
for(pargs = args ; pargs != R_NilValue; pargs = CDR(pargs)) {
#ifdef THROW_REGISTRATION_TYPE_ERROR
if(checkTypes &&
!comparePrimitiveTypes(checkTypes[nargs], CAR(pargs), dup)) {
/* We can loop over all the arguments and report all the
erroneous ones, but then we would also want to avoid
the conversions. Also, in the future, we may just
attempt to coerce the value to the appropriate
type. This is why we pass the checkTypes[nargs] value
to RObjToCPtr(). We just have to sort out the ability
to return the correct value which is complicated by
dup, etc. */
errorcall(call, _("Wrong type for argument %d in call to
%s"),
nargs+1, symName);
}
#endif
cargs[nargs] = RObjToCPtr(CAR(pargs), naok, dup, nargs + 1,
which, symName, argConverters + nargs,
checkTypes ? checkTypes[nargs] : 0,
encname);
#ifdef R_MEMORY_PROFILING
if (TRACE(CAR(pargs)) && dup)
memtrace_report(CAR(pargs), cargs[nargs]);
#endif
nargs++;
}
Thanks,
Whit
-----Original Message-----
From: r-help-bounces at r-project.org
[mailto:r-help-bounces at r-project.org] On Behalf Of Gustaf Rydevik
Sent: Wednesday, January 09, 2008 10:25 AM
To: r-help at r-project.org
Subject: [R] An "R is slow"-article
Hi all,
Reading the wikipedia page on R, I stumbled across the following:
http://fluff.info/blog/arch/00000172.htm
It does seem interesting that the C execution is that much
slower from R than from a native C program. Could any of the
more technically knowledgeable people explain why this is so?
The author also have some thought-provoking opinions on R
being no-good and that you should write everything in C
instead (mainly because R is slow and too good at graphics,
encouraging data snooping). See
http://fluff.info/blog/arch/00000041.htm
While I don't agree (granted, I can't really write C), it
was interesting to read something from a very different
perspective than I'm used to.
Best regards,
Gustaf
_____
Department of Epidemiology,
Swedish Institute for Infectious Disease Control work email:
gustaf.rydevik at smi dot ki dot se skype:gustaf_rydevik