[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