[R] An "R is slow"-article

Jeffrey Horner jeff.horner at vanderbilt.edu
Wed Jan 9 17:11:50 CET 2008


I hazard to say that the author of that blog post isn't using the time 
he saved from writing his analyses in C very efficiently. I wonder how 
long it took him to write it in C in the first place, even to setup the 
testing of C against R, or to write the blog post.

He didn't say.

Jeff

Armstrong, Whit wrote on 01/09/2008 09:49 AM:
> 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.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ______________________________________________
> 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.


-- 
http://biostat.mc.vanderbilt.edu/JeffreyHorner




More information about the R-help mailing list