Message-ID: <c0839f85-3474-ebd5-08b6-7066435d3d4b@umu.se>
Date: 2020-07-15T14:13:41Z
From: Göran Broström
Subject: Openblas?
In-Reply-To: <24334.63547.147901.993925@rob.eddelbuettel.com>
On 2020-07-15 14:36, Dirk Eddelbuettel wrote:
>
> G?ran,
>
> This is not an easy email to reply to because it _contains nothing
> reproducible_.
Thanks Dirk,
Sorry about that, but my real question was (see below): "Is the problem
that openblas uses C versions of blas?" That is, do I need to change
F77_CALL(name)(...);
to
cblas_name(...);
everywhere? And if so, is this really a good idea with old code?
I'll try to extract a reproducible example from the package (eha) where
I run it.
G?ran
>
> 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
>