similar to: OpenBLAS in everyday R?

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,

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

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-

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

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

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

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

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

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

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,

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

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,

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*

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

So as long as I can read, OpenBlas, for Windows, might be a worth considering option: http://www.openblas.net But Intel MKL also seems to be free*: https://software.intel.com/en-us/articles/free-mkl Thank you, Juan El 30/10/2017 6:45 p. m., "Avraham Adler" <avraham.adler at gmail.com> escribi?: > [Sent offlist accidentally] > > What concerns me first and foremost is

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

Multi-threaded Math Libraries (Trough OpenBlas), taking into account that today's laptops have a minimum of 2-4 cores, are an important topic, and in my opinion, shall be included in R for the general interest. I think that the way to go would be to create a configuration setting in R's options(OpenBlas= TRUE|FALSE) which enables or disables OpenBlas in an easy way, which by default shall