similar to: OpenBLAS in everyday R?

I didn't do the compile; is there a way to check whether that was used? If not, I'll inquire with our sysadmin and report back. In any case, my suggestion was motivated by the fact that some parts of R use OpenMP while others do not, in the hope that the former could have their OpenBLAS omelet without breaking the OpenMP eggs, so to speak. On 01/09/2018 06:41 PM, Keith O'Hara

Thanks Keith. We checked, and indeed libopenblas is not linked against libomp nor libgomp. We suspect this is because we used conda to install R and OpenBLAS. So I guess we should be barking up the conda tree instead? By the way, I also noticed on my home machine (Ubuntu), /usr/lib/libopenblas.so.0 is also not linked against those, for what that's worth. Regards, Ben On 01/10/2018 12:04

Julia Programming Language uses also OpenBlas, and it is actively maintained with bugs being fixed as I have checked it out: http://www.openblas.net/Changelog.txt So I still see it ok to be included as an options(...) feature (by default off, just for safety), over other Blas libraries. R could not use Intel MKL for legal reasons (I think), because as long that R ships with GPL libraries,

It seems like many of the multi-threaded BLASes have some sort of fundamental problem preventing use in the way Juan suggests: - Dirk's vignette states that ATLAS "fixes the number of cores used at compile-time and cannot vary this setting at run-time", so any user-friendly implementation for R would have to compile ATLAS for 1-16 threads to allow the user to switch at run-time.

Do those issues still arise when OpenBLAS is compiled with USE_OPENMP=1 ? Keith > On Jan 9, 2018, at 6:03 PM, Benjamin Tyner <btyner at gmail.com> wrote: > > Please pardon my ignorance, but doesn't OpenBLAS still not always play nicely with multi-threaded OpenMP? (for example, don't race conditions sometimes crop up)? If so, it might be nice to have the ability to

True or False: when USE_OPENMP=1 is not used, then race conditions are not unexpected. If True, and we wish to avoid race conditions, then sources such as the conda channel and ubuntu would need to add this enhancement. If False, then what is the next step (i.e. forum) for debugging the race condition? On 01/11/2018 07:56 AM, Ista Zahn wrote: > > > On Jan 10, 2018 8:24 PM,

Check if libopenblas is linked against libomp or libgomp. I?d be curious to see any errors that arise when an OpenMP version of OpenBLAS is linked with R. Keith > On Jan 9, 2018, at 11:01 PM, Benjamin Tyner <btyner at gmail.com> wrote: > > I didn't do the compile; is there a way to check whether that was used? If not, I'll inquire with our sysadmin and report back.

On Jan 10, 2018 8:24 PM, "Benjamin Tyner" <btyner at gmail.com> wrote: Thanks Keith. We checked, and indeed libopenblas is not linked against libomp nor libgomp. We suspect this is because we used conda to install R and OpenBLAS. So I guess we should be barking up the conda tree instead? What are you barking about? I don't understand what you are trying to accomplish. By

I?m not really familiar with conda, but if they?re being packaged together then an omp build might be more appropriate. Perhaps another point for Juan?s list: whether OpenBLAS is the right choice to pair with. The library itself hasn?t produced optimized kernels for any of the Intel *Lake chips yet; might be worth considering its near- and long-term future (vs something else). Keith > On

Hi R-devel list, OpenBLAS is readily available for unix-likes: https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf However, my questions are: 1) Would R-devel consider using OpenBLAS for the main distribution of R for all platforms including Windows? 2) If so, would R-devel set the default multi-thread level to the number of (real) cores on a machine? My sense is there're a

On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell <kmbell56 at gmail.com> wrote: > It seems like many of the multi-threaded BLASes have some sort of > fundamental problem preventing use in the way Juan suggests: > > - Dirk's vignette states that ATLAS "fixes the number of cores used at > compile-time and cannot vary this setting at run-time", so any > user-friendly

Hello, macosx 10.13.6, Rdevel r76458 I'm trying to compile against openblas to reproduce an error on the CRAN check page (my package is clean under winbuilder and all but one of the checks). I've downloaded and installed openblas 0.3.7 but I am not 100% sure that it is being used by R. Using ./configure --with-blas="-lopenblas" Then running R to discover the PID I get:

[Sent offlist accidentally] What concerns me first and foremost is that the licensure would have to be ironclad (including for commercial use like vanilla R now) as well as ensuring that R remains completely FLOSS. Anything ?added? to R has to be a no-strings-attached gift to R. Also, I would think that it would have to play nice with existing workflows (like OpenBLAS instead of MKL) unless

On Wed, Jan 10, 2018 at 12:04 AM, Keith O'Hara <keith.ohara at nyu.edu> wrote: > > Check if libopenblas is linked against libomp or libgomp. > > I?d be curious to see any errors that arise when an OpenMP version of OpenBLAS is linked with R. > > Keith > The one time I tried compiling OpenBLAS for Windows 64 with USE OMP = 1, I got an error. I don't recall if it

> On 6 Feb 2019, at 10:58, Martin Maechler <maechler at stat.math.ethz.ch> wrote: > ..... > --------------------------------------------------------------------------- > > I summarize what has been reported till: > > Failure in these cases > ======== > 1. Kasper K ("Scientific Linux", self compiled R, using Intel's MKL > for BLAS/LAPACK)

Hi Avraham, What a coincidence, I have been following this post of yours: https://www.avrahamadler.com/2013/10/24/an-openblas-based-rblas-for-windows-64-step-by-step/ Looks like this post is slightly older than what you have shared previously. It is strange that you did not get the attachments. I am pasting the contents of the MkRules.local here:

Hello. I seem to be having the same problem that Paul had in the thread titled "[Rd] R 2.15.2 make check failure on 32-bit --with-blas="-lgoto2"" from October of last year <https://stat.ethz.ch/pipermail/r-devel/2012-October/065103.html> Unfortunately, that thread ended without an answer to his last question. Briefly, I am trying to compile an Rblas for Windows NT 32bit

I believe that repo just follows the directions on my blog. Without seeing Dr. Hodges?s code, my initial concern is the many references to Cygwin. My method specifically does not use Cygwin but MSYS2 and Mingw64/Rtools35. That will likely change to solely Rtools40 once R3.6 is released due to the Msys system being built in to it. There may be some library conflicts between Cygwin and

Hi All, I am trying to compile R from source on a 64 bit Windows. I have downloaded and installed all the third party software as per the R - documentation. The compilation starts fine and after a while it stops with the following error message: D:/Rtools/mingw_64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lRgraphapp collect2.exe: error: ld

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