My apologies! I was looking at the current documentation and was
unable to find anything related to this topic in the mailing list
after Milan's question but you are correct. I moved to the latest MKL
and from R-2.14.2 to R-2.15.0 this morning and it appears to build
fine now.
A few months ago I had to link against the GNU OpenMP library
(libgomp) instead of the intel OpenMP library (libiomp5) to avoid the
"double complex BLAS" error and I thought it would be worthwhile to
share this insight.
I do still think that
MKL_LIB_PATH=/opt/intel/mkl/10.0.3.020/lib/em64t/
should be changed to
MKL_LIB_PATH=/opt/intel/mkl/lib/intel64/
Looks like a lot can change in just a few months :) Sorry again, next
time I will be sure to try the latest version.
Thanks,
Elliott Forney
On Wed, May 30, 2012 at 2:02 AM, Prof Brian Ripley
<rip...@stats.ox.ac.uk> wrote:
> 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<nalimi...@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@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>> ______________________________________________
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> Brian D. Ripley, rip...@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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
