R help - Jan 2002 - MKL seems to beat ATLAS, but some problems... (was RE: linkin g R against MKL)

Hi all,

I managed to at least compile R-patched (2002-01-08) against MKL 5.1 (not
beta).  The release notes for MKL said that the libraries are threaded, and
the test codes needed to be linked against the pthread library.  Therefore I
added -lpthread flag in config.site for R-patched, and the compile went
through.  However, when I did make check, it choked on a call to La.eigen,
complaining that "lapack routines cannot be loaded".  If anyone can
provide
some hints, I'd really appreciate it.  Note: MKL is claimed to contain full
lapack routines.

The test that Thomas referred to on the ATLAS list is at:
http://www.geocrawler.com/archives/3/15666/2001/9/0/

The note said that MKL 5.1 beta was not compared because of NDA on the beta.
Since the one I downloaded is not beta, and there are no NDA clause in the
license, I suppose I won't be sued for posting the following comparison.

For n=1000, 10000, and 100000, x is matrix(runif(n*100), n, 100). y is
runif(n).  I compared the timing for crossprod(x,x), qr(x), and lm(y ~ x).
Reported below are results of system.time()[1]:

          n       x'x    qr(x)   lm(y ~ x)
ATLAS321  1000    0.04    0.18    0.75
MKL51     1000    0.03    0.12    0.72

ATLAS321  10000   0.37    2.83    6.12
MKL51     10000   0.28    2.77    6.08

ATLAS321  1e+05   3.76   33.48   53.7
MKL51     1e+05   2.76   27.23   47.26

So it does seem to provide some modest improvement over ATLAS, at least on
this particular machine (dual P3-866 Xeon with 2GB RDRAM).

Regards,
Andy

> -----Original Message-----
> From: Thomas Lumley [mailto:tlumley at u.washington.edu]
> Sent: Friday, January 11, 2002 2:42 PM
> To: Liaw, Andy
> Cc: 'r-help at stat.math.ethz.ch'
> Subject: Re: [R] linking R against MKL
> 
> 
> On Fri, 11 Jan 2002, Liaw, Andy wrote:
> > Also, has anyone compared MKL with ATLAS?  Maybe it's not 
> worth the effort
> > fooling with MKL?
> 
> There's some discusssion on the math-atlas-results list at the ATLAS
> sourceforge page.  It looks as though it probably isn't worth 
> the effort
> at least for double precision reals. YMMV.
> 
> Another thing to note is that ATLAS is reporting substantial slowdowns
> with gcc 3 especially on Athlons but even on Intel chips.
> 
> 	-thomas
> 
> Thomas Lumley			Asst. Professor, Biostatistics
> tlumley at u.washington.edu	University of Washington, Seattle
> 
> 
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at
stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

On Tue, 15 Jan 2002, Liaw, Andy wrote:
> I managed to at least compile R-patched (2002-01-08) against MKL 5.1 (not
> beta).  The release notes for MKL said that the libraries are threaded, and
> the test codes needed to be linked against the pthread library.  Therefore
I
> added -lpthread flag in config.site for R-patched, and the compile went
> through.  However, when I did make check, it choked on a call to La.eigen,
> complaining that "lapack routines cannot be loaded".  If anyone
can provide
> some hints, I'd really appreciate it.  Note: MKL is claimed to contain
full
> lapack routines.
R cannot currently make use of anyone else's LAPACK routines (because
we've found too many problems with them).

If you are getting no useful diagnostics, try
dyn.load("RHOME/modules/lapack.so").  That ought to tell you why you
can't
load it.  My guess would be to do with libraries, so do an ldd on
lapack.so and check that all the dependencies are resolved as you expect.
> The test that Thomas referred to on the ATLAS list is at:
> http://www.geocrawler.com/archives/3/15666/2001/9/0/
> The note said that MKL 5.1 beta was not compared because of NDA on the
beta.
> Since the one I downloaded is not beta, and there are no NDA clause in the
> license, I suppose I won't be sued for posting the following
comparison.
>
> For n=1000, 10000, and 100000, x is matrix(runif(n*100), n, 100). y is
> runif(n).  I compared the timing for crossprod(x,x), qr(x), and lm(y ~ x).
> Reported below are results of system.time()[1]:
>
>           n       x'x    qr(x)   lm(y ~ x)
> ATLAS321  1000    0.04    0.18    0.75
> MKL51     1000    0.03    0.12    0.72
>
> ATLAS321  10000   0.37    2.83    6.12
> MKL51     10000   0.28    2.77    6.08
>
> ATLAS321  1e+05   3.76   33.48   53.7
> MKL51     1e+05   2.76   27.23   47.26
>
> So it does seem to provide some modest improvement over ATLAS, at least on
> this particular machine (dual P3-866 Xeon with 2GB RDRAM).
I would not expect those to benefit much from a tuned BLAS.  qr is not
based on LAPACK, and so only uses level-1 BLAS.


-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at
stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._