Package Details: r-mkl 4.0.5-1

Git Clone URL: https://aur.archlinux.org/r-mkl.git (read-only, click to copy)
Package Base: r-mkl
Description: Language and environment for statistical computing and graphics, linked to the Intel(R) MKL.
Upstream URL: http://www.r-project.org/
Keywords: hpc mathematics modelling r statistics
Licenses: GPL
Conflicts: microsoft-r-open, r
Provides: r=4.0.5
Submitter: giniu
Maintainer: alexanderp
Last Packager: alexanderp
Votes: 21
Popularity: 0.22
First Submitted: 2010-05-06 00:10
Last Updated: 2021-04-07 14:53

Dependencies (25)

Required by (390)

Sources (5)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 ... Next › Last »

blazko commented on 2019-05-04 06:58

Thanks it worked.

The new version (with newest intel-mkl) does not recognize all 32 cores on my xeon. When running simr() it now uses only 16, and with previous version it used all of them at 100%.

Is this something I can restore?

As a side note: other multicore applications still can run at 100% resources. It's something that changed for R only

alexanderp commented on 2019-05-03 12:48

https://wiki.archlinux.org/index.php/Pacman#%22Failed_to_commit_transaction_(conflicting_files)%22_error

blazko commented on 2019-05-03 12:08

@alexanderp thing is, there are a couple of those (survival.R) is just one of them. Is there any --overwrite all option? :)

error: failed to commit transaction (conflicting files)
r-mkl: /usr/lib/R/library/rpart/help/figures/rpart.png exists in filesystem
r-mkl: /usr/lib/R/library/survival/doc/survival.R exists in filesystem
r-mkl: /usr/lib/R/library/survival/doc/survival.Rnw exists in filesystem
r-mkl: /usr/lib/R/library/survival/doc/survival.pdf exists in filesystem
r-mkl: /usr/lib/R/library/survival/help/figures/logo.png exists in filesystem
Errors occurred, no packages were upgraded.
==> WARNING: Your packages are saved in /tmp/yaourt-tmp-bajzel

alexanderp commented on 2019-05-03 11:36

@blazko Try adding --overwrite usr/lib/R/library/survival/doc/survival.R to your pacman command. My own installations upgraded fine by the way.

blazko commented on 2019-05-03 11:00

I'm getting r-mkl: /usr/lib/R/library/survival/doc/survival.R already exists in filesystem with a couple others when trying to upgrade from last 3.5 version. Should I remove old install completely before trying to upgrade?

alyst commented on 2019-04-23 12:35

@alexanderp My laptop's march is skylake. I can try some R benchmarks/tests (which ones do you have in mind?) with the current r-mkl CFLAGS (-O3 -m64 -march=native -I...) vs the proposed ones (${CFLAGS} -m64 -I..., where $CFLAGS is from makepkg.conf with "-march=x86_64" set by default).

The second part (intel compiler dependency) should not affect it, though. There was a problem before was intel-mkl implicitly depending on intel-compiler-based, but I've just fixed it.

There's another potential issue that R-MKL uses Intel OpenMP with GCC compiler instead of GCC's own implementation. As some of the R packages may explicitly use -fopenmp, this may cause some issues either at compile or run time. Here's a fix for that:

@@ -113,16 +118,16 @@ build() {
     export FFLAGS="${_intel_cc_opt}"
     export FCFLAGS="${_intel_cc_opt}"
   else
     _gcc_opt=" -O3 -m64 -march=native -I${MKLROOT}/include"
     # export LDFLAGS=" -fopenmp"

     # Dynamic Linking
     _mkllibs=" -L${MKLROOT}/lib/${_intel_arch} \
       -Wl,--no-as-needed \
       -l${_gfortran_lib} \
-      -lmkl_intel_thread \
+      -lmkl_gnu_thread \
       -lmkl_core \
-      -liomp5 \
+      -fopenmp \
       -lpthread \
       -lm \
       -ldl"

alexanderp commented on 2019-04-22 19:54

@alyst Thanks for the diff. You make an interesting point, especially about respecting the users' makepkg.conf.

From my own experience, linking R with the MKL is very sensitive with respect to compiler flags and requires some fine-tuning to make sure that base R and some popular libraries compile correctly and that tests do not fail or deviate from the expected value. Carrying over any custom settings set in makepkg.conf could introduce errors.

What is the output of gcc -c -Q -march=native --help=target | grep -i 'march=\|mtune='? Could you provide compilation, test and benchmark logs for comparing the current PKGBUILD with the proposed changes?

I think the way forward would be to introduce a local variable to switch between native and makepkg.conf (generic) flags. I'd also be interested in hearing others' opinion on this.

alyst commented on 2019-04-22 16:28

Here's the proposed changes. I have also made the dependencies dynamically depend on _CC var (so that GCC-compiled package doesn't depend on intel compilers) + removed !makeflags (it only affected MAKEFLAGS anyway):

diff --git a/PKGBUILD b/PKGBUILD
index 8a315e6..77fc4f7 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -13,12 +13,8 @@ url='http://www.r-project.org/'
 provides=("r=${pkgver}")
 conflicts=('r' 'microsoft-r-open')
 depends=('intel-mkl'
-        'intel-compiler-base'
-        'intel-fortran-compiler'
         'bzip2'
         'desktop-file-utils'
-        'gcc-libs'
-        'gcc-fortran'
         'icu'
         'libjpeg'
         'libpng'
@@ -44,7 +40,7 @@ backup=('etc/R/Makeconf'
         'etc/R/ldpaths'
         'etc/R/repositories'
         'etc/R/javaconf')
-options=('!makeflags' '!emptydirs')
+options=('!emptydirs')
 install=r-mkl.install

 source=("http://cran.r-project.org/src/base/R-${pkgver%%.*}/R-${pkgver}.tar.gz"
@@ -65,6 +61,15 @@ sha512sums=('077cbd4bc9f19a3a2485afbd4d8e08e0754ddcb9a10164cbc8478f239d5ed0ffaf6
 # Comment the following line to build the package with GCC
 # _CC="icc"

+# update dependencies w.r.t the compiler used
+if [[ $_CC = "icc" ]]; then
+  depends+=('intel-compiler-base'
+            'intel-fortran-compiler')
+else
+  depends+=('gcc-libs'
+            'gcc-fortran')
+fi
+
 prepare() {
   cd R-${pkgver}
   # set texmf dir correctly in makefile
@@ -113,7 +118,7 @@ build() {
     export FFLAGS="${_intel_cc_opt}"
     export FCFLAGS="${_intel_cc_opt}"
   else
-    _gcc_opt=" -O3 -m64 -march=native -I${MKLROOT}/include"
+    _gcc_opt="-m64 -I${MKLROOT}/include"
     # export LDFLAGS=" -fopenmp"

     # Dynamic Linking
@@ -133,10 +138,10 @@ build() {
     export LD="ld"
     export F77="gfortran"
     export FC="gfortran"
-    export CFLAGS="${_gcc_opt}"
-    export CXXFLAGS="${_gcc_opt}"
-    export FFLAGS="${_gcc_opt}"
-    export FCFLAGS="${_gcc_opt}"
+    export CFLAGS="$CFLAGS ${_gcc_opt}"
+    export CXXFLAGS="$CXXFLAGS ${_gcc_opt}"
+    export FFLAGS="$FFLAGS ${_gcc_opt}"
+    export FCFLAGS="$FCFLAGS ${_gcc_opt}"
   fi

   ./configure  --prefix=/usr \

alyst commented on 2019-04-22 15:03

Currently, r-mkl overrides the -march GCC switch from "makepkg.conf" and sets it to "native". While I understand the intention, this creates problems for some scenarios.

E.g. I'm trying to make a docker image for a slightly different architecture than my local machine. So I have the proper "-march" switch in "makepkg.conf", but it would be ignored by r-mkl PKGBUILD. One possibility would be to fix the PKGBUILD from within Dockerfile, but that doesn't play well with using AUR helpers like yay or pikaur to automatically manage dependencies.

Would it be possible to implement either: 1) respect XXXFLAGS set by makepkg.conf and only minimally modify them (just append "-m64 -I...") 2) change PKGBUILD to -march=$CC_ARCH, where CC_ARCH is some envvar that defaults to "native"?

pat-s commented on 2018-08-12 17:33

@nessuno Well, the most recent icu is v62.1 so maybe that the reason why the fix does not work for you? Other libraries (including r-mkl) using icu need to be reinstalled after an icu update to work with the most recent version.

Anyways, r-mkl does not have any responsibility here so the discussion is actually off-topic.