similar to: solved(?) (was RE: MKL seems to beat ATLAS, but some problems...)

Prof. Ripley, > From: Prof Brian Ripley [mailto:ripley at stats.ox.ac.uk] [snipped...] > R cannot currently make use of anyone else's LAPACK routines (because > we've found too many problems with them). > > If you are getting no useful diagnostics, try > dyn.load("RHOME/modules/lapack.so"). That ought to tell you > why you can't > load it. My

Prof. Ripley, > From: Prof Brian Ripley [mailto:ripley at stats.ox.ac.uk] [snipped...] > R cannot currently make use of anyone else's LAPACK routines (because > we've found too many problems with them). > > If you are getting no useful diagnostics, try > dyn.load("RHOME/modules/lapack.so"). That ought to tell you > why you can't > load it. My

Hi all, I managed to at least compile R-patched (2002-01-08) against MKL 5.1 (not beta). The release notes for MKL said that the libraries are threaded, and the test codes needed to be linked against the pthread library. Therefore I added -lpthread flag in config.site for R-patched, and the compile went through. However, when I did make check, it choked on a call to La.eigen, complaining that

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

On Mon, Aug 24, 2015 at 1:42 PM, Dirk Eddelbuettel <edd at debian.org> wrote: > > On 24 August 2015 at 11:43, arnaud gaboury wrote: > | On Mon, Aug 24, 2015 at 11:29 AM, Bj?rn-Helge Mevik > | <b.h.mevik at usit.uio.no> wrote: > | > arnaud gaboury <arnaud.gaboury at gmail.com> writes: > | > > | >> - Intel MKL: this is part of Intel Parallel Studio

On 24 August 2015 at 11:43, arnaud gaboury wrote: | On Mon, Aug 24, 2015 at 11:29 AM, Bj?rn-Helge Mevik | <b.h.mevik at usit.uio.no> wrote: | > arnaud gaboury <arnaud.gaboury at gmail.com> writes: | > | >> - Intel MKL: this is part of Intel Parallel Studio and is a paid | >> software. Now, there is the MKL package distributed by | >> Revolutionanalytics, but I

On Mon, Aug 24, 2015 at 11:29 AM, Bj?rn-Helge Mevik <b.h.mevik at usit.uio.no> wrote: > arnaud gaboury <arnaud.gaboury at gmail.com> writes: > >> - Intel MKL: this is part of Intel Parallel Studio and is a paid >> software. Now, there is the MKL package distributed by >> Revolutionanalytics, but I am not certain how this can be distributed >> for free. Is

I want to build R optimized, with either MKL, OpenBLAS or ATLAS. My OS: Fedora 22 Hardware: CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 Thread(s) per core: 2 Vendor ID: GenuineIntel Model name: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz I am a little confused when it comes to choose a method and would like to hear your experiences. If I am right, I have 3 possibilities: -

Emmanuel, On 30 August 2008 at 00:04, Emmanuel Charpentier wrote: | Dear list, | | Setup : Ubuntu Hardy + updates + backports + security + R repository on | a 3.2 GHz PIV dual-core processor. | | Bitten (again...) by the "I'll optimize my setup" bug, I tried to test | atlas. Following Dirk's advice on a not-so-recent post to R-help, I | tried "apt-get install -s

Dear R-help, Has anyone tried linking R against the Intel Math Kernel Library on (obviously) Intel architecture? Since MKL claimed to provide optimized BLAS and Lapack, I thought it might be possible to compile R against it w/o too much trouble. My first naive try under Linux (Mandrake 7.1), using R-patched dated Jan. 4, 2002: ./configure --with-blas=/usr/local/intel/mkl/LIB/libmkli32_p3.a

I believe that actually means configure was able to use the BLAS you specified (MKL in this case). You can scan through config.log to make sure. Andy > From: > > Fedora Core 3 > > I installed the Intel MLk, > > and tried : --with-blas="-lmkl -lguide -lpthread" > > and got : External libraries: readline, BLAS(generic) > > thus I'm

Hi folks, if you want to use MKL (the fast BLAS I have tested on my Thinkpad T410) with the R 2.14.0 built as Debian/Ubuntu packages available on CRAN mirror, the following tricks may works for without some known side-effects (likes openmp breaking issues), you may try to build your own libblas.so.3gf.0 with following command: $ gfortran -L/opt/intel/lib/intel64 -liomp5

> I would appreciate any insights over compiling R 3.4 with Intel MKL -- I have been successful until R 3.3.3 but now it stops complaining about pcre though it worked without Intel MKL as follows, I successfully built R-rc_2017-04-19_r72555.tar.gz with icc & MKL on centos 7 with this: # https://software.intel.com/en-us/articles/build-r-301-with-intel-c-compiler-and-intel-mkl-on-linux#

Dear Thomas, thank you for your input. I've debugged one of the packages and I confirm that the breakage is related to passing of strings from C to Fortran. Indeed, BLAS and LAPACK define a large number of subroutines that take one or more explicit single-character strings as arguments. Other than that, BLAS has only one function (xerbla), which takes a string of unspecified length,

Dear Robert, try setting these MKL environment variables export MKL_INTERFACE_LAYER=GNU,LP64 export MKL_THREADING_LAYER=GNU the example should then report correct results (and regardless of the version of R). There is no need to rebuild R from source, but when you are building from source, this problem would be detected by checks in R configure scripts. I can reproduce the problem on Ubuntu

Dear all, Given that the Intel MKL multithreaded BLAS is now free (https://software.intel.com/en-us/mkl/choose-download, released under the very permissive Intel Simplified Software License, https://software.intel.com/en-us/license/intel-simplified-software-license) and that this BLAS comes out as the fastest in most benchmarks, and that Microsoft R Open compiled against Intel MKL seems to be

Hi Tomas, That does the trick, thanks! In fact, I had those lines commented out in my Rmkl startup script but I can't remember why, since they're part of Intel's instructions. Strange that things still worked for somewhat older Rs. (Perhaps that's why I canceled them.) Dirk, if you're listening, it might help to add a note to your blog post. I guess it's not as simple

I am having trouble of compiling R 3.0.2 with MKL 11.1.0.080; tried the following resources: http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor http://cran.r-project.org/doc/manuals/R-admin.html#MKL http://software.intel.com/en-us/comment/reply/328415 and getting the following: *checking for dgemm_ in -Wl,--start-group -lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core -Wl,--end-group

This may not be a proper question to ask here, however I don't find a better place to ask. I am testing Ubuntu Natty 11.04. I build R with Blas/Lapack linked to intel MKL. Everything works fine but when quitting R with q(), the R process won't quit, and the system monitor shows its waiting channel as futex_wait_queue_me. For example, with "make check", the process will halted

There is nothing here indicating any kind of error, so no way to give any insights .... And please do follow the posting guide, including not posting HTML. FWIW, I have tested R 3.4.0 RC (sic) with MKL 11.3, which is later than your 2013 ... (on x86_64 Fedora 24). On 20/04/2017 10:39, jing hua zhao wrote: > Dear R-developers, > > > I would appreciate any insights over compiling R