similar to: Pointer to fourteen patches to speed up R

I've continued to work on speeding up R, and now have a collection of fourteen patches, some of which speed up particular functions, and some of which reduce general interpretive overhead. The total speed improvement from these patches is substantial. It varies a lot from one R program to the next, of course, and probably from one machine to the next, but speedups of 25% can be expected in

I've been inspired to look at the R source code by some strange timing results that I wrote about on my blog at radfordneal.wordpress.com (see the posts on "Speeding up parentheses..." and "Two surprising things...". I discovered that the strange speed advantage of curly brackets over parentheses is partially explained by an inefficiency in the evalList and

Looking for more ways to speed up R, I've found that large improvements are possible in the speed of "sum" and "prod" for long real vectors. Here is a little test with R version 2.11.1 on an Intel Linux system > a <- seq(0,1,length=1000) > system.time({for (i in 1:1000000) b <- sum(a)}) user system elapsed 4.800 0.010 4.817 > system.time({for (i

As I mentioned in my previous message about speeding up evalList, I've been looking at ways to speed up the R interpreter. One sees in the code many, many calls of PROTECT, UNPROTECT, and related functions, so that seems like an obvious target for optimization. Indeed, I've found that one can speed up the interpreter by about 10% by just changing these. The functions are actually macros

I've looked at the code for matrix multiplies in R, and found that it can speeded up quite a bit, for multiplies that are really vector dot products, and for other multiplies in which the result matrix is small. Here's my test program: u <- seq(0,1,length=1000) v <- seq(0,2,length=1000) A2 <- matrix(2.1,2,1000) A5 <- matrix(2.1,5,1000) B3 <- matrix(3.2,1000,3) A4 <-

> From: "Cohn, Robert S" <robert.s.cohn at intel.com> > > I am using R to multiply some large (30k x 30k double) matrices on a > 64 core machine (xeon phi). I added some timers to > src/main/array.c to see where the time is going. All of the time is > being spent in the matprod function, most of that time is spent in > dgemm. 15 seconds is in matprod in

Hi, I'm just following your messages the overhead that the code for dealing with possible NA/NaN values brings. When I was setting up part of the matrixStats package, I've also though about this. I was thinking of having an additional logical argument 'hasNA'/'has.na' where you as a user can specify whether there is NA/NaN:s or not, allowing the code to avoid it or not.

I found a bug in one of the fourteen speed patches I posted, namely in patch-vec-subset. I've fixed this (I now see one does need to duplicate index vectors sometimes, though one can avoid it most of the time). I also split this patch in two, since it really has two different and independent parts. The patch-vec-subset patch now has only some straightforward (locally-checkable) speedups for

Hi, Jean-Marc, and thanks for the quick reply. Let me just say I'm a huge fan of speex, and the work you've done. I actually barely understand what I'm reading so far in the source code and documentation, just enough to understand just how cool the algorithms are. LPC10 and MELP allow me to speed up speech with a simple hack on the decoder frame size. Playing fewer samples per

I see that some of the speed patches that I posted have been incorporated into the current development version (eg, my patch-for, patch-evalList, and patch-vec-arith). My patch for speeding up x^2 has been addressed in an inadvisable way, however. This was a simple addition of four lines of code that speeds up squaring of real vectors by a factor of about six (for vectors of length 10000), by

Hi all: Below is a patch against 2.5.6 which fixes a problem when more than MAXLONG (2147483648) bytes are in the file system when statistics are output (and the compiler supports long long). Before the patch, I would get a core dump during statistics generation on large f. Now I can get statistics like: wrote 1139440 bytes read 20 bytes 17666.50 bytes/sec total size is 2154562788 speedup

Hi, Steve. I tried your the time_scale_tests program, and it works well! Especially for low speed changes, it's the best I've heard so far. For high speed increases, there is what sounds like static added to the sound output. I've attached two sound samples of high speed speech, which is a 4X speed up of a popular TTS voice in the blind community (voxin/Eloquence). I've sped

Hugh, (Note I speak for myself only and not for R-core) Thanks for looking into this. I think it's great to have community members that are interested in contributing to R and helping it continue to get better. And I think, and my local experiments bear out, that using anyNA as a fastpass condition does allow us to get a significant speedup over what's in there now. To do so, though, I

Thanks Radford. I concur with all your points. I've attempted to address the issues you raised through the github.io post. The new method appears to be slower for test lengths < 100 and possibly longer lengths (not just < 10). Of course length(test) < 100 is very quick, so I simply added this to the conditions that cause the old ifelse method to be invoked. I'll leave it to

Venables and Ripley describe a speedup where you take a structure like x<-NULL for(i in sequence) y<-c(y,function(x,i)) and convert it to one like x<-numeric(its length) for(i in sequence) y[i]<-function(x,i) I tried this speedup on some simple examples and it made them twice as fast. But now I am hitting a snag with some real code. This original version works:

You're asking the wrong question. The question is not "why does it would bad with Speex?", but "why does it sound good with LPC10 and MELP?". And the answer is that both are vocoders. Try dropping frames/subframes with anything else (Vorbis, MP3, G.729, u-law, ...) and it'll sound terrible as well. The only reason it sounds good with vocoders is because the

Some might have noticed that REvolution Computing released the doSMP package to the general public about a month and a half ago, which allows multiple cores to be accessed for parallel computation in R. Some of our physical habitat calculations were taking an extraordinary amount of time to complete and required over-weekend runs, which prompted our interest in this package. What follows

This is a great example how you cannot figure it out after spending two hours troubleshooting, but a few minutes after you post to R-devel, it's just jumps to you (is there a word for this other than "impatient"?); Let me answer my own question. The discrepancy between my sum2() code and the internal code for base::sum() is that the latter uses LDOUBLE = long double (on some system

> I propose a patch to ifelse that leverages anyNA(test) to achieve an > improvement in performance. For a test vector of length 10, the change > nearly halves the time taken and for a test of length 1 million, there > is a tenfold increase in speed. Even for small vectors, the > distributions of timings between the old and the proposed ifelse do > not intersect. For smaller

Hi, I was wondering if I could use the matprod function from array.c in my own C routine. I tried the following as a test /* my_matprod.c */ # include <Rinternals.h> /* for REAL, SEXP etc */ # include <R_ext/Applic.h> /* array.c says need for dgemm */ /* following copied from array.c */ static void matprod(double *x, int nrx, int ncx, double *y, int nry, int ncy, double *z)