similar to: Changing the BLAS from openblas on a F32 box

Of course, even a simpler trick is to launch R as follows: LD_PRELOAD=/lib64/atlas/libsatlas.so.3 R and then the symbols in libsatlas take precedence over libopenblas. Or a mix between both alternatives, i.e., setting LD_PRELOAD=/path/to/some/link R and then change that link to point to openblas, atlas... Whatever suits you best. I?aki On Wed, 27 May 2020 at 11:00, I?aki Ucar <iucar at

Thanks I?aki, that is exactly what i was looking for, esp the last option which I have now configured as an alias for easy remembering. I can answer the question re USE_LOCKING=1. I think that using both those options is required to get thread-safety even if openblas was compiled for single thread use. I don't know to what extent Simon has engaged with upstream on this etc. All I know is

Hi Gavin, On Wed, 27 May 2020 at 01:15, Gavin Simpson <ucfagls at gmail.com> wrote: > > Dear list, > > What is the recommended incantation on Fedora 32 to swap out the > openblas BLAS that the packaged (rpm) version of R-core installs for > ATLAS? I'm afraid there is no official mechanism in place to do that yet. There was a proposal [1], but it was never pushed

On Wed, 27 May 2020 at 21:40, Gavin Simpson <ucfagls at gmail.com> wrote: > > Thanks I?aki, that is exactly what i was looking for, esp the last > option which I have now configured as an alias for easy remembering. > > I can answer the question re USE_LOCKING=1. I think that using both > those options is required to get thread-safety even if openblas was > compiled for

On Wed, 27 May 2020 at 23:03, Gavin Simpson <ucfagls at gmail.com> wrote: > > Thanks (again) I?aki. > > There was a typo in my reply above. I should have said: I *can't* > answer the question re USE_LOCKING=1. :) > Those other suggestions are really helpful too; I really didn't > understand what the difference was (I'm still not clear what the >

Thanks (again) I?aki. There was a typo in my reply above. I should have said: I *can't* answer the question re USE_LOCKING=1. Those other suggestions are really helpful too; I really didn't understand what the difference was (I'm still not clear what the differences are between say openblas-openmp and openblas-openmp64), but I did get R to pass mgcv's thread safe test with both

I run Fedora 22 R package. It is build with --with-lapack \ --with-blas \ --enable-R-shlib \. As the machine will act as a server with lots of R data computing, I try to optimize my R package. At first, I installed parallel_studio_xe_2016 with a free one year licence. Then, I build a package for R with Intel MKL and compiler. This took me lots of time as it was my first .rmp build. I finally

Hello R-sig-debian and (hopefully) Dirk: On Debian wheezy, I have the R packaging that CRAN (you) provide. I run into a little trouble while trying to fiddle with alternative BLAS. I know you and I went around on this last year and I think perhaps I've found something wrong in the framework, or I've just done something wrong. I installed the packages openblas-base and openblas-dev, and

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

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.so.0 is also not linked against those, for what that's worth. Regards, Ben On 01/10/2018 12:04

On Wed, Jan 10, 2018 at 12:04 AM, Keith O'Hara <keith.ohara at nyu.edu> 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 OMP = 1, I got an error. I don't recall if it

Has anyone succeeded in getting a parallel BLAS, such as Goto's BLAS, installed on a machine running Ubuntu 11.10? I currently have the libatlas3gf-base package installed on a machine with an AMD Athlon X4 processor. I tried to install the libopenblas-base and libopenblas-dev packages but there seemed to be a glich related to having both libopenblas and libatlas3gf installed so that when I

Il 30/04/20 03:39, Dirk Eddelbuettel ha scritto: > > On 30 April 2020 at 03:26, Samuele Carcagno wrote: > | I'm not familiar with the internals of `viridisLite`, so I'm not sure > | I'd be able to help there. I could open a bug report on the > | `viridisLite` repo and see if the author has suggestions on how to > | narrow down the issue. > > It would help if

Hi, I tried to compile R with openblas on a ubuntu 12.04 machine. I have to say that I normally use the package system and that I have no experience with compiling R. I did the following: ./configure --enable-BLAS-shlib --enable-R-shlib LIBnn=lib --with-blas="-L/usr/lib/openblas-base/ -lopenblas" --enable-memory-profiling --with-x=yes go the output: R is now configured for

Hi there, On 1 December 2017 at 23:24, G?ran Brostr?m wrote: | Dirk, | | thanks for your help. At work I have (ubuntu 16.04): | | ii libblas-common 3.6.0-2ubuntu2 amd64 Dependency package for | all BLAS implementations | ii libblas-dev 3.6.0-2ubuntu2 amd64 Basic Linear Algebra | Subroutines 3, static library | ii libblas3 3.6.0-2ubuntu2 amd64 Basic Linear

Den 2017-12-01 kl. 20:24, skrev Dirk Eddelbuettel: > > On 1 December 2017 at 19:55, G?ran Brostr?m wrote: > | Hello, > | > | the following is a part of a question asked on R-help. I realized that > | it is better suited for asking here. Apologies for the cross-posting! > | > | I'm on Ubuntu artful, and upgraded with 'apt'. Then > | > |

Hello, the following is a part of a question asked on R-help. I realized that it is better suited for asking here. Apologies for the cross-posting! I'm on Ubuntu artful, and upgraded with 'apt'. Then ---------------------------------------------------------------- goran at M6800:~/src/R-3.4.3$ /usr/bin/R /usr/lib/R/bin/exec/R: symbol lookup error:

Dear All, I am building R from source[1], following what is done in "rules" for building Debian's R. But the R I generate, in contrast to the standard Debian's R, will not change the BLAS and LAPACK libraries it uses when I change them via "update-alternatives". I have no idea what I am doing wrong (but, somehow, I've been quite capable of making the same

Thank you very much Dirk! Le mer. 13 mai 2020 ? 14:59, Dirk Eddelbuettel <edd at debian.org> a ?crit : > > Salut Adrien, > > It appears to be a bad OpenMP and and OpenBLAS interaction you can (for > now) > avoid) by replacing the 'pthread' variant of OpenBLAS with the OpenMP > version > (see the thread for details). Doing > > sudo apt install

I have upgraded R (from 3.6 to 4.0) and RStudio (from 1.1 to 1.2.5) a few days ago, and Ubuntu from 18.04 to 20.04 yesterday. Since then, R sometimes never terminates when executing certain commands: ivreg (from package AER), summary (of a logit regression) and logitmfx (from package mfx). Sometimes these commands run fine, but most of the time I have to kill the process because R won't