[Rd] OpenBLAS in everyday R?

Benjamin Tyner
Tue, 09 Jan 2018 23:03:12 -0000

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* reassuring.
>
> I agree that having it included as an options(...) feature should be OK.
>
> On Sun, Dec 17, 2017, 3:22 PM Juan Telleria <jtelleriar at gmail.com
<https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote:
>
> >/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, shipping R by default with Non-GPL
is />/illegal. />//>/Cheers, />/Juan />//>/El 17/12/2017 2:50
a. m., "Avraham Adler" <avraham.adler at gmail.com
> <https://stat.ethz.ch/mailman/listinfo/r-devel>> />/escribi?:
/>//>>/On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell <kmbell56 at
gmail.com
> <https://stat.ethz.ch/mailman/listinfo/r-devel>> 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
implementation for R would have to compile ATLAS for
> 1-16 />>/> threads to allow the user to switch at run-time. This
might
> dramatically />>/> affect install times. />>/>
/>>/> - MKL seems like it's been outright rejected in the past
based on not />>/> being "free-enough". />>/>
/>>/> - OpenBLAS causes crashes. />>/> />>/> Has
anyone tried ExBLAS for use with R? />>/> />>/> On Sun, Dec
17, 2017 at 1:03 PM, Peter Langfelder < />>/> peter.langfelder at
gmail.com
> <https://stat.ethz.ch/mailman/listinfo/r-devel>> wrote:
/>>/> />>/>> 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 />>//>>/I've been
building R on Windows 64 bit with OpenBLAS for years and my />>/builds
pass check-devel. For a while in the past it failed one check />>/as the
tolerance was 5e-5 and with my build of OpenBLAS the error was />>/5.4e-5
or 5.7e-5, but that was changed around R 3.3, if I recall />>/correctly. I
provide descriptions here [1], but I haven't gone so far />>/as to
post compiled Rblas.dlls just yet. My personal build sets 4 />>/threads
when compiling OpenBLAS itself as I'm currently on a quad-core
/>>/SandyBridge. In tests I ran a few years ago, both single and multi
/>>/threaded BLAS compile and then can be compiled into R with no issues
/>>/(on my platforms, at least). Most matrix operations performed better
/>>/with multi-threaded except for R's eigenvalue decomposition, to
the />>/nest of my recollection. />>//>>/Avi
/>>//>>/[1]
https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/
/>>//>>/______________________________________________
/>>/R-devel at r-project.org
> <https://stat.ethz.ch/mailman/listinfo/r-devel> mailing list
/>>/https://stat.ethz.ch/mailman/listinfo/r-devel />>//>//
> 	[[alternative HTML version deleted]]