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 <jl...@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:da...@revolution-computing.com] > Sent: Thursday, April 23, 2009 6:05 PM > To: Jason Liao > Cc: r-help@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 <jl...@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 <da...@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 <da...@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 ______________________________________________ R-help@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.