On Mon, Aug 23, 2010 at 10:39 PM, Radford Neal <radf...@cs.toronto.edu> wrote: >> On Aug 23, 2010, at 7:39 PM, Radford Neal wrote: > >> > In particular, all matrix x vector and vector x matrix products will >> > in this version be done in the matprod routine, not the Fortran routine. >> > And this is the right thing to do, since the time for the ISNAN check >> > before calling the Fortan routine will be comparable to the time for >> > the matrix multiply. So avoiding it will be desirable unless the Fortran >> > routine is really, really faster than the C code in matprod. >> >> It is, many times in fact, if you use threaded BLAS on a multi-core machine >> and large matrices. > > Well, it can't get any faster than taking zero time. And even in that > case, using the C code in matprod will slow the program down (compared > to the existing version of R) by only about a factor of two. > >> > Of course, the real solution is to change the Fortran routine (which >> > seems to be in src/extra/blas/blas.f, and isn't all that complicated) >> >> Nope - it can be external and BLAS standard doesn't handle NAs. > > OK. I see the problem if people can link in their own version of BLAS. > I wonder if there is any way of telling whether they did that? Presumably > many people will use the BLAS routine supplied with R, which could be > made safe for NAs.
Radford: this is highly platform dependent. For example, all OS X users use a multithreaded BLAS supplied by Apple. And I believe a multithreaded BLAS is used by Revolution R (all platforms). Allowing a plugin BLAS is (in my opinion) an essential advantage of R and is used by many people who care about high performance. Note that the BLAS version can be swapped after R has been compiled, so even if there is a way to tell what BLAS you are using (and I don't know if there is), it has to be a run-time check. Kasper ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
