Package Details: r-mkl 4.4.1-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
Submitter: giniu
Maintainer: alexanderp
Last Packager: alexanderp
Votes: 25
Popularity: 0.000301
First Submitted: 2010-05-06 00:10 (UTC)
Last Updated: 2024-07-04 19:34 (UTC)

Required by (3401)

Sources (5)

Latest Comments

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

alexanderp commented on 2019-05-06 18:36 (UTC)

@blazko, I need something to test this claim. Can you please provide a reproducible example that made use of all cores before the update but does not now?

blazko commented on 2019-05-06 18:24 (UTC)

@alexanderp My .conf file is set up as before:

# Confgure the MKL multithreading
# for more details visit: http://software.intel.com/sites/products/documentatio>
#

# Uncomment if you want to set a constant number o threads.
export MKL_NUM_THREADS=32

# Uncomment and edit if you want to set the nr. of threads for every components.
# export MKL_DOMAIN_NUM_THREADS="MKL_ALL=4, MKL_BLAS=4"

# If TRUE MKL set automatically the optimal number of threads
#export MKL_DYNAMIC=TRUE

That does not help. I'm not sure what does this switch mean, but is there a way to make it use Intel back again?

alexanderp commented on 2019-05-06 18:05 (UTC) (edited on 2019-05-06 18:07 (UTC) by alexanderp)

@blazko The package recently switched from Intel threading to OpenMP. Can you please try setting the number of threads manually in /etc/intel-mkl-th.conf?

mys_721tx commented on 2019-05-05 16:30 (UTC) (edited on 2019-05-05 16:48 (UTC) by mys_721tx)

The -limf flag causes a problem when compiling acepack since /opt/intel/compilers_and_libraries_2019.3.199/linux/compiler/lib/intel64 is not in $FLIBS. The problem is resolved by adding -L/opt/intel/compilers_and_libraries_2019.3.199/linux/compiler/lib/intel64 to $FLIBS in /usr/lib/R/etc/Makeconf. Perhaps we should append it to wherever -limf appears.

> install.packages("acepack")
trying URL 'https://cloud.r-project.org/src/contrib/acepack_1.4.1.tar.gz'
Content type 'application/x-gzip' length 34848 bytes (34 KB)
==================================================
downloaded 34 KB

* installing *source* package ‘acepack’ ...
** package ‘acepack’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
gfortran  -fpic  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include   -c ace.f -o ace.o
gfortran  -fpic  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include   -c avas.f -o avas.o
gfortran  -fpic  -m64 -I/opt/intel/compilers_and_libraries_2019.3.199/linux/mkl/include   -c rlsmo.f -o rlsmo.o
gcc -shared -L/usr/lib64/R/lib -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -o acepack.so ace.o avas.o rlsmo.o -lgfortran -limf -lm -lquadmath -L/usr/lib64/R/lib -lR
/usr/sbin/ld: cannot find -limf
collect2: error: ld returned 1 exit status
make: *** [/usr/share/R//make/shlib.mk:6: acepack.so] Error 1
ERROR: compilation failed for package ‘acepack’
* removing ‘/usr/lib/R/library/acepack’
* restoring previous ‘/usr/lib/R/library/acepack’

The downloaded source packages are in
    ‘/tmp/RtmpZqWncs/downloaded_packages’
Warning message:
In install.packages("acepack") :
  installation of package ‘acepack’ had non-zero exit status

blazko commented on 2019-05-04 06:58 (UTC) (edited on 2019-05-04 07:05 (UTC) by blazko)

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 (UTC) (edited on 2019-05-03 12:48 (UTC) by alexanderp)

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

blazko commented on 2019-05-03 12:08 (UTC) (edited on 2019-05-03 12:45 (UTC) by blazko)

@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 (UTC)

@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 (UTC)

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 (UTC)

@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"