Comments on: Fourteen patches to speed up R

By: Readability vs speed in R

Readability vs speed in R — Sat, 19 Feb 2011 12:12:07 +0000

[...] why you are referred to his article. He also found a interesting observation about squares. In a further article he presents some patches to speed up [...]

By: Radford Neal

Radford Neal — Fri, 15 Oct 2010 04:19:39 +0000

I’ve now found out what causes the bug. It’s a problem with the internal DispatchOrEval function, which I didn’t modify, but which my patch-dollar code uses in a different way than the $ operator did previously. This problem with DispatchOrEval causes other (rather obscure) bugs in other R primitives (eg, xtfrm). I’ll soon report the bug, with a fix.

R version 2.12.0 is due to be released shortly. I’ll be putting out versions of my patches (except the ones that have been incorporated into 2.12.0) for it. I think it isn’t worth while putting out a fixed patch-dollar for R 2.11.1.

The symptom that arises in ggplot2 is that, with my patch-dollar, a method for $ that deparses the first argument will not work correctly.

By: Radford Neal

Radford Neal — Tue, 05 Oct 2010 21:18:28 +0000

I’ve narrowed the bug Filip found down to something in patch-dollar. More once I find what it actually is…

By: Radford Neal

Radford Neal — Tue, 05 Oct 2010 20:03:13 +0000

Hi. I’ve just gotten time to look at this now. I can reproduce the problem you report, so there’s presumably a bug somewhere in one of my patches. I’ll investigate further…

By: Filip

Filip — Sun, 03 Oct 2010 17:20:21 +0000

Dear, thank You for the patches, I have observed a speed-ups of up to 50% on my Intel Core 2 Duo, 2 Ghz, 4GiB RAM machine. I think I have found a bug though, as this code (and similar ones, everything including geom_bar in ggplot2 package) :

library(ggplot2)
a = 3
b = 7
s = 10
f = 11
ps = rbeta(1000, a + s, b + f)
qplot(ps,..density.., geom=”histogram”, binwidth = 0.01)

Returns:

“Error in if (empty(data)) return(data.frame()) : missing value where TRUE/FALSE needed”

While running smoothly on vanilla R.

By: Radford Neal

Radford Neal — Thu, 09 Sep 2010 03:45:49 +0000

The patch to matrix product is the one with the most peculiar effects. On SPARC machines it makes thinkgs much slower, because when the matrix product is done in the R matprod procedure, it accumulates sums in “long double” form, which is extraordinarily slow on our SPARC machine. Maybe something like that is happening on your machine. But are you sure the CRAN version used the same compiler (and options) as you did for the patched version? If not, the comparision would be less informative.

The matrix product patch can also potentially change the answer, since roundoff error is not necessarily the same as for the BLAS routine. This makes checking the results of the R test suite difficult.

The matrix product patch’s motivation is that R doesn’t trust NA treatment by the BLAS routines, and so spends time checking for them, which can be avoided if it instead just does the product itself. It’s not clear to me that this check is desirable, and if its not, the patch would instead be to just delete this check.

By: Mike Lawrence

Mike Lawrence — Thu, 09 Sep 2010 01:16:04 +0000

oops, make that OS 10.6.4, and gfortran-42-5664

By: Mike Lawrence

Mike Lawrence — Thu, 09 Sep 2010 01:09:35 +0000

Interesting. I tested my machine (unibody macbook, 2.4 GHz Intel C2D, 4GB RAM, OS 10.6.3) on R 11.1 binary provided by CRAN, then downloaded 11.1′s source, patched, and built (annoyingly had to upgrade my gfortran to 2.4.4 in order to build, but this was the case with the unpatched source too [I checked]). The speed tests all seemed better for the patched version *except* the matprod tests:

CRAN binary:
2.916, 1.488, 1.12, 1.497, 2.491, 3.752, 4.111

Patched:
1.309, 1.42, 1.592, 1.271, 3.997, 6.303, 8.777

I actually ran the test on the CRAN binary twice (once before and after shutting down other apps), so even though the timings look weird (non-monotonic), they came out roughly the same across both runs.

By: In{s}a(ne)!! « Xi'an's Og

In{s}a(ne)!! « Xi'an's Og — Sun, 05 Sep 2010 22:08:52 +0000

[...] the latest of his posts, Radford lists a series of 14 patches that speed up R up to 25%… That R can face [...]

By: stewart

stewart — Sat, 04 Sep 2010 23:53:47 +0000

I redid my tests without calling C code: I see around 10% improvement in overall time for my GS. The gains are pretty much across the board, but I do notice that for matrix operator “%*%” the gain is big: it cuts the time by 1/3,that looks like a huge deal to me! I am sending you the Rprof results FYI.