My surprising experience in trying out REvolution's R
You can always turn the multi-threading off with: setMKLthreads(1) We tested your code with this setting, and it ran in exactly the same time as CRAN R. # David Smith
On Fri, Apr 24, 2009 at 7:34 AM, Jason Liao <JLIAO at hes.hmc.psu.edu> wrote:
David, thanks for following this through. I do not know how big a matrix needs to be before the multi-core multi-threading will start save time. But it seems useful to build this protection in your distribution so that it will not do multi-core when multi-threading is more likely to do harm. Jason -----Original Message----- From: David M Smith [mailto:david at revolution-computing.com] Sent: Thursday, April 23, 2009 6:05 PM To: Jason Liao Cc: r-help at r-project.org Subject: Re: [R] My surprising experience in trying out REvolution's R We've taken a look at this in a bit more detail; it's a very interesting example. ?Although the code uses several functions that exploit the parallel processing in REvolution R (notably %*% and chol), this was one of those situations where the overheads of threading pretty much balanced any performance gains: the individual matrices for the operations were too small. For some examples where the performance gains do show, see: http://www.revolution-computing.com/products/r-performance.php A more promising avenue for speeding up this code lies in parallelizing the outer for(i in 1:200) loop... # David Smith On Tue, Apr 21, 2009 at 9:26 AM, Jason Liao <JLIAO at hes.hmc.psu.edu> wrote:
I care a lot about R's speed. So I decided to give REvolution's R (http://revolution-computing.com/) a try, which bills itself as an optimized R. Note that I used the free version. My machine is a Intel core 2 duo under Windows XP professional. The
code
I run is in the end of this post. First, the regular R 1.9. It takes 2 minutes and 6 seconds, CPU usage 50% Next, REvolution's R. It takes 2 minutes and 10 seconds, CPU usage
100%.
In other words, REvolution's R consumes double the CPU with slightly less speed. The above has been replicated a few times (as a statistician of
course).
Anyone has any insight on this? Anyway, my high hope was dashed.
-- David M Smith <david at revolution-computing.com> Director of Community, REvolution Computing www.revolution-computing.com Tel: +1 (206) 577-4778 x3203 (San Francisco, USA) Check out our upcoming events schedule at www.revolution-computing.com/events
David M Smith <david at revolution-computing.com> Director of Community, REvolution Computing www.revolution-computing.com Tel: +1 (206) 577-4778 x3203 (San Francisco, USA) Check out our upcoming events schedule at www.revolution-computing.com/events