On Wed, 8 May 2019 at 18:00, Ralf Stubner wrote:
>
> On 08.05.19 09:34, Iñaki Ucar wrote:
> > On Wed, 8 May 2019 at 04:52, Peter Langfelder
> > wrote:
> >>
> >> (CCing the R-devel list, maybe someone will have a better answer.)
> >>
> >> To be honest, I don't know how to. I wasn't able to configu
On Wed, May 8, 2019 at 9:00 AM Ralf Stubner wrote:
> AFAIK a single-threaded OpenBLAS is used. When compiling R from source
> on a CentOS system I have used the configure option
> '--with-blas="-lopenblasp"' to link with the pthread version of OpenBLAS.
Yes, that's the right incantation. Thanks
On 08.05.19 09:34, Iñaki Ucar wrote:
> On Wed, 8 May 2019 at 04:52, Peter Langfelder
> wrote:
>>
>> (CCing the R-devel list, maybe someone will have a better answer.)
>>
>> To be honest, I don't know how to. I wasn't able to configure R to use
>> OpenBLAS using the configure script and options on
On Wed, 8 May 2019 at 04:52, Peter Langfelder
wrote:
>
> (CCing the R-devel list, maybe someone will have a better answer.)
>
> To be honest, I don't know how to. I wasn't able to configure R to use
> OpenBLAS using the configure script and options on my Linux Fedora system.
> I configure it witho
On 7 May 2019 at 19:43, Peter Langfelder wrote:
| (CCing the R-devel list, maybe someone will have a better answer.)
|
| To be honest, I don't know how to. I wasn't able to configure R to use
| OpenBLAS using the configure script and options on my Linux Fedora system.
| I configure it without ex
(CCing the R-devel list, maybe someone will have a better answer.)
To be honest, I don't know how to. I wasn't able to configure R to use
OpenBLAS using the configure script and options on my Linux Fedora system.
I configure it without external BLAS, then replace the libRblas.dylib (.so
in my case
I'm a linux guy so take the advice with a grain of salt... When you
run the configure script, look at the output at the end of the run, it
should either say
Options enabled: shared BLAS, ... (means you are using R BLAS)
or it should mention OpenBLAS in External libraries (meaning you
Dear R Developers,
I attach a complete summary of all the Know-How that has been generated
during Dec 2017 & Jan 2018 in R-devel Mailing List related to the Dynamic
Change of:
- Regular Single Threaded BLAS.
- And a Multi-threaded BLAS Implementation (e.g.: OpenBLAS):
https://kbrproject.mi
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
On Thu, Jan 11, 2018 at 10:38 AM, Keith O'Hara wrote:
[snip]
>
> 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
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 chip
On Jan 10, 2018 8:24 PM, "Benjamin Tyner" 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?
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
> In order to document the generated Know-How of Optional BLAS Libraries
> Implementation and Tests (For example: OpenBLAS), I have created a
> Mediawiki based wiki page in which anyone can document and discuss any
> issues he/she encounters:
>
> https://kbrproject.miraheze.org/wiki/Main_Page/BLAS
In order to document the generated Know-How of Optional BLAS Libraries
Implementation and Tests (For example: OpenBLAS), I have created a
Mediawiki based wiki page in which anyone can document and discuss any
issues he/she encounters:
https://kbrproject.miraheze.org/wiki/Main_Page/BLAS
I will mys
I won’t play nicely with a package that combines omp pragmas with calls to BLAS
routines, e.g. something you might get with source Armadillo/Eigen/Blaze code,
for reasons that Benjamin mentioned in his initial email (pthreads vs omp).
Keith
> On Jan 10, 2018, at 1:28 AM, Avraham Adler wrote:
>
On Wed, Jan 10, 2018 at 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
>
The one time I tried compiling OpenBLAS for Windows 64 with USE O
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 wrote:
>
> I didn't do the compile; is there a way to check whether that was used? I
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
Do those issues still arise when OpenBLAS is compiled with USE_OPENMP=1 ?
Keith
> On Jan 9, 2018, at 6:03 PM, Benjamin Tyner 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
> c
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 th
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 wrote:
> Julia Programming Language uses also OpenBlas, and it is actively
> maintained with bugs being fixed as I have checked it out:
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
On Sat, Dec 16, 2017 at 7:41 PM, Kenny Bell 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 sett
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 w
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
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(Op
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(Op
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 wrote:
> On point 1):
>
> The standard approach seems to favor the reference BLAS for reasons oth
On Sun, Dec 17, 2017 at 10:01 AM, Dirk Eddelbuettel wrote:
>
> 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-read
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.htm
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 implement
32 matches
Mail list logo
