[R] An "R is slow"-article

[Armstrong, Whit]

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
> 
> ______________________________________________
> R-help at 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.
> 




This e-mail message is intended only for the named recipient(s) above. It may contain confidential information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you.