[Rd] Speeding up matrix multiplies

[Kasper Daniel Hansen]

On Mon, Aug 23, 2010 at 10:39 PM, Radford Neal <radford at 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