From ripley at stats.ox.ac.uk  Wed May 30 10:02:27 2012
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Wed, 30 May 2012 09:02:27 +0100
Subject: [Rd] Out of date instructions to build R using MKL
In-Reply-To: <CAMTFtYLT978dRYpqN0s1sKu5-RoHofjToMNF9wnY-v=HtGTwhQ@mail.gmail.com>
References: <1328886941.2325.23.camel@milan>
	<CAMTFtYLT978dRYpqN0s1sKu5-RoHofjToMNF9wnY-v=HtGTwhQ@mail.gmail.com>
Message-ID: <4FC5D413.9090004@stats.ox.ac.uk>

Hmm, you replied to a message from February and there has been an R 
release since with a revised manual.  That does say (even more clearly) 
that it refers to version 10.0 of MKL and there have been changes.  And 
since than there had been a change (notified by an Intel engineer) about 
which version of OpenMP to use.

In short, please always check the current documentation before posting 
(as the posting guide required of you).

On 29/05/2012 21:10, Elliott Forney wrote:
> Yes, these instructions are no longer valid as there has been some
> reorganization of the mkl libraries.  The path
> /opt/intel/mkl/10.0.3.020/lib/em64t/ is now
> /opt/intel/mkl/lib/intel64.  Also, the only libraries that need to be
> included are:
>
> -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core
>
> The trick to getting rid of the "double complex BLAS" error is to use
> only the gnu compatible libraries (i.e. use mkl_gnu_thread instead of
> iomp5).  I believe the intel-only libraries use a different convention
> to pass complex numbers between libraries built with fortran?
> Thankfully this check detects the error instead of crashing at run
> time.
>
> I used the following to build R-2.14.1 with MKL:
>
> export LD_LIBRARY_PATH=/opt/intel/mkl/lib/intel64
> ./configure --prefix=/opt/R-2.14.1 --enable-threads=posix
> --with-lapack --with-blas="-I/opt/intel/mkl/include
> -L/opt/intel/mkl/lib/intel64 -lmkl_gf_lp64
> -lmkl_gnu_thread -lmkl_core -fopenmp -lpthread -lm"
>
> Although a highly tuned BLAS may not help much for many applications,
> I have seen several orders of magnitude performance improvement in
> some of my work that uses matrix operations heavily and others in my
> lab have experienced the same.  Having R linked against MKL has been
> HUGELY important for me personally.
>
> A custom tuned ATLAS works well too but I find it frustrating that it
> needs to be re-tuned for each architecture I use (I tend to distribute
> jobs in a heterogeneous environment).
>
> Thanks!
>    Elliott Forney
>
> On Fri, Feb 10, 2012 at 8:15 AM, Milan Bouchet-Valat<nalimilan at club.fr>  wrote:
>> Hi!
>>
>> I've been playing with MKL for a few days and I noticed the instructions
>> in the R Installation Administration manual [1] no longer apply. It
>> seems that since version 10.0 (the one used by the manual),
>> libmkl_lapack.so has been renamed/split (although the official
>> explanations seem to imply this was already the case in 10.0 [2]).
>>
>> As a consequence, the instructions for dynamic linking no longer work
>> with the last version (2011-sp1). This is also the case of what is
>> explained on several sites like [3] or [4]. The manual's instructions to
>> link statically to MKL still work fine, though.
>>
>> I'm merely signaling this fact to more clued people, since I've not been
>> able to get R to dynamically link to MKL. I'm always getting this notice
>> during ./configure:
>>> checking whether double complex BLAS can be used... no
>>
>> Anyways, one of the problems is also that it's no longer possible to
>> make libRblas.so and libRlapack.so symlinks to the Intel libs, as they
>> are split into several files.
>>
>> If nobody knows how or cares about to fix this ATM, a simple warning
>> that the instructions are outdated would already improve the situation,
>> as it took me some time to understand things had changed and I wasn't
>> just being silly. ;-)
>>
>> (That said, I'm not convinced using an external BLAS/LAPACK is really
>> interesting for standard desktops. Performances gains compared to
>> default packages are incredible in benchmarks, but for real use cases
>> multi-threading often makes things slower - at least for me, using gnm.
>> I guess this is mostly interesting for very larges matrices, and not for
>> many repeated small operations.)

And that is well-attested, including in the R manuals.

>>
>> Regards
>>
>>
>> 1: http://cran.r-project.org/doc/manuals/R-admin.html#MKL
>> 2: http://software.intel.com/en-us/forums/showthread.php?t=81302
>> 3:
>> http://www.r-bloggers.com/compiling-64-bit-r-2-10-1-with-mkl-in-linux/
>> 4: http://www.rd.dnc.ac.jp/~otsu/lecture/RwithMKL.html
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


-- 
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 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595



[Rd] Out of date instructions to build R using MKL
Prof Brian Ripley