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, "Benjamin Tyner" <bty...@gmail.com
<mailto:bty...@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 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 AM, Keith O'Hara 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
On Jan 9, 2018, at 11:01 PM, Benjamin Tyner
<bty...@gmail.com <mailto:bty...@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.
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 wrote:
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 <mailto: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 <http://gmail.com>
<https://stat.ethz.ch/mailman/listinfo/r-devel
<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
<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
<http://gmail.com>
<https://stat.ethz.ch/mailman/listinfo/r-devel
<https://stat.ethz.ch/mailman/listinfo/r-devel>>>
/>/escribió: />//>>/On Sat, Dec 16, 2017
at 7:41 PM, Kenny Bell <kmbell56 at
gmail.com <http://gmail.com>
<https://stat.ethz.ch/mailman/listinfo/r-devel
<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 <http://gmail.com>
<https://stat.ethz.ch/mailman/listinfo/r-devel
<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/
<https://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/>
/>>//>>/______________________________________________
/>>/R-devel at r-project.org
<http://r-project.org>
<https://stat.ethz.ch/mailman/listinfo/r-devel
<https://stat.ethz.ch/mailman/listinfo/r-devel>>
mailing list
/>>/https://stat.ethz.ch/mailman/listinfo/r-devel
<https://stat.ethz.ch/mailman/listinfo/r-devel>
/>>//>//
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org
<mailto:R-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
<https://stat.ethz.ch/mailman/listinfo/r-devel>
______________________________________________
R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
<https://stat.ethz.ch/mailman/listinfo/r-devel>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
