similar to: OpenBLAS in everyday R?

On point 1): The standard approach seems to favor the reference BLAS for reasons other than speed. For example, vecLib, Apple's multi-threaded BLAS library, is not the default choice for macOS binaries due to concerns about 'precision'. See: https://cloud.r-project.org/bin/macosx/RMacOSX-FAQ.html#Whic h-BLAS-is-used-and-how-can-it-be-changed_003f This doesn't appear to be Mac-

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.

On Sun, Dec 17, 2017 at 10:01 AM, Dirk Eddelbuettel <edd at debian.org> wrote: > > Kenny, > > On 17 December 2017 at 09:28, Kenny Bell wrote: > | Hi R-devel list, > | > | OpenBLAS is readily available for unix-likes: > | > | https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf > > Please consider re-reading this vignette of mine. BLAS is an

Kenny, On 17 December 2017 at 09:28, Kenny Bell wrote: | Hi R-devel list, | | OpenBLAS is readily available for unix-likes: | | https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf Please consider re-reading this vignette of mine. BLAS is an interface, OpenBLAS is but one implementation. R has allowed you to switch between different implementations for a long time (if you used a

It seems that reproducibility across systems is also an issue with multithreaded BLASes: https://hal.archives-ouvertes.fr/hal-01202396/file/exblas.pdf On Sun, Dec 17, 2017 at 11:50 AM, Keith O'Hara <keith.ohara at nyu.edu> wrote: > On point 1): > > The standard approach seems to favor the reference BLAS for reasons other > than speed. > > For example, vecLib,

I would be very cautious about OpenBLAS in particular... from time to time I get complains from users that compiled code calculations in my WGCNA package crash or produce wrong answers with large data, and they all come from OpenBLAS users. I am yet to reproduce any of their crashes when using MKL and ATLAS BLAS implementations. Just my 2 cents... Peter On Sat, Dec 16, 2017 at 12:28 PM, Kenny

I think the thing that is missing is a simple way for end users on windows to replace blas/lapack libraries with MKL-a package that you install that puts the libraries in the right place. Microsoft provides something for their distro, but we don't have the equivalent if you get R from cran. On 29 October 2017 at 22:01, Kenny Bell wrote: | User here: incorporating Intel's MKL, as MRO

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,

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 temporarily disable multi-threaded OpenMP (effectively: omp_set_num_threads(1)) for the duration of operations using OpenBLAS. Regards Ben > Julia using OpenBLAS is *very*

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

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 29 October 2017 at 22:01, Kenny Bell wrote: | User here: incorporating Intel's MKL, as MRO does, would be a very welcome | addition. | | I was an MRO user before and it improved my experience with medium data | immensely. | | They did, however, leave behind bugs here and there, especially related to | development with Rcpp, so I switched back to vanilla R. With all due respect: You may

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

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

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,

dear debian-R group: I am using the stock ubuntu binary R 3.0.1 for ubuntu raring but on cinnamon mint olivia 15. I read dirk's gcbd paper from a couple of years ago. it suggests that stock blas is pretty bad compared to the four main alternatives. of course, dirk also maintains the binaries for debian/ubuntu R, so he probably knows the answer off hand. I installed libatlas3-base

In order to document the generated Know-How of Optional BLAS Libraries Implementation and Tests (For example: OpenBLAS), I have created a Mediawiki based wiki page in which anyone can document and discuss any issues he/she encounters: https://kbrproject.miraheze.org/wiki/Main_Page/BLAS I will myself document all observations and attach the papers that have been mentioned in R-devel related to

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

>>>>> Erin Hodgess >>>>> on Fri, 1 Mar 2019 12:30:35 -0700 writes: > Yay! I re-installed everything and got through "Make > distribution"! I have one more question, please: I am > running the make check-all. I have an error at reg-1d. > It stops the process. However, the mean difference (as > per the file) is