Re: [Rd] Out of date instructions to build R using MKL
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 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.) > > 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
Re: [Rd] Out of date instructions to build R using MKL
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 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 >> 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/L
[Rd] unexpected behavior in list of lexical closures (PR#14004)
Full_Name: Elliott Forney
Version: 2.9.2
OS: Linux, Fedora 10
Submission from: (NULL) (129.82.47.235)
The following code creates a list of functions that are lexically closed over a
single argument. If a print statement is included then each function in the
list evaluates to a different value. If the print statement is not included
then each function evaluates to something different, as expected. I am
convinced that this behavior is not correct as one would not expect the presence
of a lone print statement to alter the behavior of a program.
Please let me know if you have any questions and thank you for your time. The
sample code follows:
## returns a function that sums input with 5
funk <- function(input)
{
## expected behavior if either of
## the following lines is uncommented
# print(input)
# input <- input
## function to sum input with 5
## lexical closure over input
function()
{
input + 5
}
}
## create a list different funk's
funk.list <- list()
for (i in 1:5)
{
## just some values to sum over
test.vector <- 1:i
## add funk that sums test.vector with 5
funk.list[[i]] <- funk(sum(test.vector))
}
## print result of evaluating each funk
## They are all the same unless print or
## reflexive assignment is uncommented!!
for (i in 1:5)
print(funk.list[[i]]())
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unexpected behavior in list of lexical closures (PR#14004)
I see. I will be careful of this in the future. Thank you very much
for your feedback.
Elliott Forney
On Tue, Oct 13, 2009 at 5:59 AM, Duncan Murdoch wrote:
> On 13/10/2009 1:50 AM, elliott.for...@gmail.com wrote:
>>
>> Full_Name: Elliott Forney
>> Version: 2.9.2
>> OS: Linux, Fedora 10
>> Submission from: (NULL) (129.82.47.235)
>
> This is not a bug, just a consequence of lazy evaluation. Arguments are not
> evaluated when passed, but when first used. Since the "input" argument is
> never evaluated in the commented version of "funk" below, it isn't evaluated
> until one of the output functions is evaluated.
>
> It's a good practice to force the evaluation of arguments to function
> builders like this, for exactly the reason you saw. (The force() function
> is one way to do it, but any expression evaluating the argument will work.
>
> Duncan Murdoch
>
>
>>
>>
>> The following code creates a list of functions that are lexically closed
>> over a
>> single argument. If a print statement is included then each function in
>> the
>> list evaluates to a different value. If the print statement is not
>> included
>> then each function evaluates to something different, as expected. I am
>> convinced that this behavior is not correct as one would not expect the
>> presence
>> of a lone print statement to alter the behavior of a program.
>>
>> Please let me know if you have any questions and thank you for your time.
>> The
>> sample code follows:
>>
>> ## returns a function that sums input with 5
>> funk <- function(input)
>> {
>> ## expected behavior if either of
>> ## the following lines is uncommented
>> # print(input)
>> # input <- input
>>
>> ## function to sum input with 5
>> ## lexical closure over input
>> function()
>> {
>> input + 5
>> }
>> }
>>
>> ## create a list different funk's
>> funk.list <- list()
>> for (i in 1:5)
>> {
>> ## just some values to sum over
>> test.vector <- 1:i
>>
>> ## add funk that sums test.vector with 5
>> funk.list[[i]] <- funk(sum(test.vector))
>> }
>>
>> ## print result of evaluating each funk
>> ## They are all the same unless print or
>> ## reflexive assignment is uncommented!!
>> for (i in 1:5)
>> print(funk.list[[i]]())
>>
>> __
>> 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
