[Rd] OpenBLAS in everyday R?

Keith O'Hara
Tue, 09 Jan 2018 23:41:58 -0000

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 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]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel