Re: [Rd] Build R with MKL and ICC
On Wed, Sep 30, 2015 at 12:18 PM, arnaud gaboury
wrote:
> On Tue, Sep 29, 2015 at 8:11 PM, Nathan Kurz wrote:
>> Hi Arnaud --
>>
>> I'm glad it's working for you. I'm not sure I understand your final
>> answer. Are you saying that the version I posted worked for you as
>> given, or that you had to remove some of the other options?
>
> I say it works perfectly when using the single dynamic library
> (lmkl_rt): MKL=" -L${_mkllibpath} -lmkl_rt -lpthread -lm"
> N.B: not sure the -lm is needed, and It builds without it. It seems it
> may trigger some issues on. See[0]. Thus I removed it
>
>> Perhaps you could post the full final recipe in a way that others can
>> copy and paste if they find this thread in the future?
>
> Here it is. The script is writen for Parallel studio 2016. Change path
> accordingly if composerxe 2015.
> libRlib and libRblas are build as shared librairies. It build with
> static libraries too.
> More options can be added to configure.
> Best is to source mklvars and compilervars in a script so it won't
> polluated your shell environment once the build is done.
>
> ---
> #! /bin/sh
>
> source /opt/intel/compilers_and_libraries_2016.0.109/linux/mkl/bin/mklvars.sh
> intel64
> source /opt/intel/bin/compilervars.sh intel64
>
> _icclibpath=/opt/intel/compilers_and_lbraries_2016.0.109/linux/compiler/lib/intel64/
> _mkllibpath=${MKLROOT}/lib/intel64/
> _omp_lib=/opt/intel/lib/intel64/
>
> MKL=" -L${_mkllibpath} -lmkl_rt -lpthread"
>
> export CC="icc"
> export CXX="icpc"
> export AR="xiar"
> export LD="xild"
> export F77="ifort"
>
> export CFLAGS="-g -O3 -xHost -I${MKLROOT}/include"
> export CXXFLAGS="-g -O3 -xHost -I${MKLROOT}/include"
> export FFLAGS="-I${MKLROOT}/include"
> export FCFLAGS="-I${MKLROOT}/include"
>
> # shared libs
> ./configure --with-blas="${MKL}" --enable-R-shlib --enable-BLAS-shlib
> # static libs
> ./configure --with-blas="${MKL}" --with-lapack
>
> make -j4
> --
>
> from inside the build folder:
> -
> $ldd bin/exec/R
> linux-vdso.so.1 (0x7ffc1e853000)
> libR.so => /usr/lib64/R/lib/libR.so (0x7f747091f000)
> libRblas.so => not found !! is not yet installed in the machine !!
> libm.so.6 => /lib64/libm.so.6 (0x7f7470616000)
> libiomp5.so => /opt/intel/lib/intel64_lin/libiomp5.so (0x7f74702d5000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f74700be000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f746fea1000)
> libc.so.6 => /lib64/libc.so.6 (0x7f746fae1000)
> libdl.so.2 => /lib64/libdl.so.2 (0x7f746f8dd000)
> libblas.so.3 => not found !! we don't need it !!
> libgfortran.so.3 => /lib64/libgfortran.so.3 (0x7f746f5b1000)
> libquadmath.so.0 => /lib64/libquadmath.so.0 (0x7f746f372000)
> libreadline.so.6 => /lib64/libreadline.so.6 (0x7f746f127000)
> libtre.so.5 => /lib64/libtre.so.5 (0x7f746ef17000)
> libpcre.so.1 => /lib64/libpcre.so.1 (0x7f746eca7000)
> liblzma.so.5 => /lib64/liblzma.so.5 (0x7f746ea8)
> libbz2.so.1 => /lib64/libbz2.so.1 (0x7f746e87)
> libz.so.1 => /lib64/libz.so.1 (0x7f746e65a000)
> librt.so.1 => /lib64/librt.so.1 (0x7f746e451000)
> libicuuc.so.54 => /lib64/libicuuc.so.54 (0x7f746e0c)
> libicui18n.so.54 => /lib64/libicui18n.so.54 (0x7f746dc69000)
> libgomp.so.1 => /lib64/libgomp.so.1 (0x7f746da46000)
> /lib64/ld-linux-x86-64.so.2 (0x55fcb8058000)
> libtinfo.so.5 => /lib64/libtinfo.so.5 (0x7f746d81c000)
> libicudata.so.54 => /lib64/libicudata.so.54 (0x7f746bdf)
> libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7f746ba6e000)
>
> $ ldd lib/libRblas.so
> linux-vdso.so.1 (0x7ffc5f3da000)
> libmkl_rt.so => /opt/intel/mkl/lib/intel64_lin/libmkl_rt.so
> (0x7f232203e000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f2321e21000)
> libm.so.6 => /lib64/libm.so.6 (0x7f2321b19000)
> libimf.so => /opt/intel/lib/intel64_lin/libimf.so (0x7f2321621000)
> libsvml.so => /opt/intel/lib/intel64_lin/libsvml.so (0x7f2320762000)
> libirng.so => /opt/intel/lib/intel64_lin/libirng.so (0x7f2320559000)
> libiomp5.so => /opt/intel/lib/intel64_lin/libiomp5.so (0x7f2320218000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f2320001000)
> libintlc.so.5 => /opt/intel/lib/intel64_lin/libintlc.so.5 (0x7f231fda1000)
> libc.so.6 => /lib64/libc.so.6 (0x7f231f9e1000)
> libdl.so.2 => /lib64/libdl.so.2 (0x7f231f7dd000)
> /lib64/ld-linux-x86-64.so.2 (0x55ce12e09000)
> --
>
>
>>
>> Also, did you determine if the the same approach worked for linking to
>> MKL worked when using a non-Intel compiler? That is, can you
>> substitute the gcc or clang tool names and get the same result?
>
> No. I was not enable to do it with gcc. More tries are needed with
> some variations.
>>
>> --nate
>>
[Rd] identical(..., ignore.environment=TRUE)
It seems odd/inconvenient to me that the "ignore.environment" argument
of identical() only applies to closures (which I read as 'functions' --
someone can enlighten me about the technical differences between
functions and closures if they like -- see below for consequences of my
confusion). This is certainly not a bug, it's clearly documented, but
it seems like a design flaw. It would certainly be convenient to be
able to ignore differences in environments when comparing complex
objects with lots of deeply nested formula and terms objects with
environments ...
Can anyone suggest a reason for this design?
Example:
> f1 <- formula()
> f2 <- formula()
> environment(f2) <- new.env()
> identical(f1,f2)
[1] FALSE
> identical(f1,f2,ignore.environment=TRUE)
[1] FALSE
Actually, maybe I don't understand how this is supposed to work since I
thought this would be TRUE:
> f1 <- function() {}
> f2 <- function() {}
> environment(f1) <- new.env()
> environment(f2) <- new.env()
> identical(f1,f2,ignore.environment=TRUE) ## FALSE
Maybe the problem *is* that I don't know the difference between a
function and a closure ... ?
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical(..., ignore.environment=TRUE)
On 11/10/2015 8:05 PM, Ben Bolker wrote:
>
> It seems odd/inconvenient to me that the "ignore.environment" argument
> of identical() only applies to closures (which I read as 'functions' --
> someone can enlighten me about the technical differences between
> functions and closures if they like -- see below for consequences of my
> confusion). This is certainly not a bug, it's clearly documented, but
> it seems like a design flaw. It would certainly be convenient to be
> able to ignore differences in environments when comparing complex
> objects with lots of deeply nested formula and terms objects with
> environments ...
>
>Can anyone suggest a reason for this design?
>
> Example:
>
>> f1 <- formula()
>> f2 <- formula()
>> environment(f2) <- new.env()
>> identical(f1,f2)
> [1] FALSE
>> identical(f1,f2,ignore.environment=TRUE)
> [1] FALSE
>
> Actually, maybe I don't understand how this is supposed to work since I
> thought this would be TRUE:
>
>> f1 <- function() {}
>> f2 <- function() {}
>> environment(f1) <- new.env()
>> environment(f2) <- new.env()
>> identical(f1,f2,ignore.environment=TRUE) ## FALSE
Those two functions likely have different srcref attributes. If you
created f2 using f2 <- f1, you'd get your expected result.
>
> Maybe the problem *is* that I don't know the difference between a
> function and a closure ... ?
In R, there is no difference. All functions are closures.
Some people only use "closure" for functions returned as the value of
other functions. That may be correct usage in other languages, but not
in R.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] identical(..., ignore.environment=TRUE)
On 11/10/2015 10:36 PM, Duncan Murdoch wrote:
> On 11/10/2015 8:05 PM, Ben Bolker wrote:
>>
>> It seems odd/inconvenient to me that the "ignore.environment" argument
>> of identical() only applies to closures (which I read as 'functions' --
>> someone can enlighten me about the technical differences between
>> functions and closures if they like -- see below for consequences of my
>> confusion). This is certainly not a bug, it's clearly documented, but
>> it seems like a design flaw. It would certainly be convenient to be
>> able to ignore differences in environments when comparing complex
>> objects with lots of deeply nested formula and terms objects with
>> environments ...
>>
>>Can anyone suggest a reason for this design?
>>
>> Example:
>>
>>> f1 <- formula()
>>> f2 <- formula()
>>> environment(f2) <- new.env()
>>> identical(f1,f2)
>> [1] FALSE
>>> identical(f1,f2,ignore.environment=TRUE)
>> [1] FALSE
>>
>> Actually, maybe I don't understand how this is supposed to work since I
>> thought this would be TRUE:
>>
>>> f1 <- function() {}
>>> f2 <- function() {}
>>> environment(f1) <- new.env()
>>> environment(f2) <- new.env()
>>> identical(f1,f2,ignore.environment=TRUE) ## FALSE
>
> Those two functions likely have different srcref attributes. If you
> created f2 using f2 <- f1, you'd get your expected result.
>
>>
>> Maybe the problem *is* that I don't know the difference between a
>> function and a closure ... ?
>
> In R, there is no difference. All functions are closures.
>
> Some people only use "closure" for functions returned as the value of
> other functions. That may be correct usage in other languages, but not
> in R.
Sorry, I meant all user functions are closures. There are other kinds
of function in R called "primitives" (e.g. c(), many low level math
functions, the functions that implement flow control, etc.).
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
