Do those issues still arise when OpenBLAS is compiled with USE_OPENMP=1 ?

Keith

> On Jan 9, 2018, at 6:03 PM, Benjamin Tyner <bty...@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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to