[R-sig-Debian] Openblas?
Dirk Eddelbuettel
edd @end|ng |rom deb|@n@org
Wed Jul 15 14:36:11 CEST 2020
Göran,
This is not an easy email to reply to because it _contains nothing
reproducible_.
On 15 July 2020 at 13:24, Göran Broström wrote:
| Hello,
|
| I thought that I should try openblas when building a CRAN package
| containing lots of old (twentieth century) C-code with frequent calls to
| blas and lapack routines. I have the following options on my Ubuntu
| 20.04 machine:
|
| Selection Path Priority Status
| ------------------------------------------------------------
| * 0 openblas-pthread/libblas.so.3 100 auto mode
| 1 blas/libblas.so.3 10 manual mode
| 2 openblas-openmp/libblas.so.3 95 manual mode
| 3 openblas-pthread/libblas.so.3 100 manual mode
|
| I tried all four alternatives by timing one particular function call and
| got quite surprising (to me) results:
|
| Selection user system elapsed
| 0 3.279 1.839 1.900
| 1 0.899 0.052 0.953
| 2 158.948 3.661 20.915
| 3 3.277 1.894 1.908
|
| Comments on that?
How could I comment? I do not know what code you ran.
| To me it seems clear that openblas (0, 2, 3) has
| nothing to offer me, as my C code stands now. Is the problem that
| openblas uses C versions of blas? I am using the Fortran version via
|
| F77_CALL(name)
|
| I tried adding
|
| PKG_CFLAGS = $(SHLIB_OPENMP_CFLAGS)
| PKG_LIBS = $(SHLIB_OPENMP_CFLAGS)
This is missing LAPACK and BLAS so ...
|
| to src/Makevars, but then I got
|
| ...undefined symbol: dsytri_
... so get a _linker error_ about missing symbols.
| when compiling.
You meant linking, not compiling.
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org
More information about the R-SIG-Debian
mailing list