Re: LAPACK vs. OpenBLAS

[Paul Garlick]

Hi Ludo,

> A surprisingly large number of packages depend on ‘lapack’:

> Perhaps we could have a lint checker warning against the use of
lapack.

Good idea.  Possibly with a helpful message along the lines of 'the
openblas package provides a LAPACK interface'.

I encountered this issue when packaging an optimization package [0]
recently.  The build system, cmake, requires a path to the BLAS_LIBRARY
and also a path to the LAPACK_LIBRARY.  One can see how the shared
library liblapack.so, provided by the lapack package, could be the
first (but mistaken) choice for the packager.

I notice that Debian [1] use NO_LAPACK=1 as an extra make option for
openblas.  This  has the effect of generating a liblapack.so file.

For the case of optizelle, the package I was working on, I labelled the
openblas input as "blas/lapack" to make it clear that the package has a
dual purpose.

Best regards,

Paul.

[0] https://hpc.guix.info/package/optizelle
[1] https://sources.debian.org/src/openblas/0.3.13+ds-3/debian/rules/

Re: LAPACK vs. OpenBLAS

[Eric Brown]

Ludovic Courtès  writes:

> Hi Eric,
>
> Eric Brown  skribis:
>
>> There are scenarios where reference BLAS is more stable and/or
>> reproducible than optimized BLAS libraries.  Sometimes its lack of
>> knowledge of OpenBLAS and/or a numerical issue.
>>
>> (cf. GNU R's discussion of which BLAS to use.)
>
> Do you have a pointer to that discussion?
>
> Are there other cases where netlib BLAS is considered more appropriate
> than OpenBLAS because it’s more numerically stable?
>
> Thanks for your feedback,
> Ludo’.

Also:

* More controversially: consider 64-bit addressing.  It is depressing to
  hit 32-bit memory limits on large machines which ought to accomodate
  larger problems. (e.g. -fdefault-integer-8, ILP64)

Re: LAPACK vs. OpenBLAS

[Eric Brown]

Hi Ludo'!

Ludovic Courtès  writes:

> Hi Eric,
>
> Eric Brown  skribis:
>
> Are there other cases where netlib BLAS is considered more appropriate
> than OpenBLAS because it’s more numerically stable?
>

Sorry about that, the full discussion is here:

https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Linear-algebra

To answer your question on other examples:
I would have to do some digging for the exact details, but there was
once a time when LAPACK 3.x had an SVD that would solve with QR, most
expensive but would give an answer for the "most singular" of problems.
It is not, however, the "published" LAPACK algorithm and is not available.

(A classic case where this occurs is when throwing junk into a linear
regression, whose solution is bullet-proof with the SVD.  Very important
for R, and many more langs and other problems such as factor analysis.)

A few random points:

* Good/improving compilers gfortran,gcc often make the reference
lapack/blas fast enough.  IIRC it is good as any optimized BLAS for
small matrices. If reporting e.g. convergence issues, people converge
here for apples-to-apples.

* ATLAS can empirically tune for architectures that are not getting love
by the OpenBLAS team.  So, non-amd64 has *something* more performant
than Reference LAPACK/BLAS.  I've often seen distributed binaries have
to choose something lackluster to satisfy older processors.

* I usually use OpenBLAS because it also gives SMP.  I notice it doesn't
  cover all the archs that Guix covers, but I think it should be default
  go-to unless of problems for x86_64 at least.

* If memory serves, layering multiple LAPACKs came from the days when
  the optimized BLAS's where incomplete. People just slapped -llapack on
  the end to make sure that if the optimized lib didn't get it then
  lapack would, just that would be only at Fortran speed :-(   lol

Best regards,
Eric

Re: LAPACK vs. OpenBLAS

[Ludovic Courtès]

Hi Eric,

Eric Brown  skribis:

> There are scenarios where reference BLAS is more stable and/or
> reproducible than optimized BLAS libraries.  Sometimes its lack of
> knowledge of OpenBLAS and/or a numerical issue.
>
> (cf. GNU R's discussion of which BLAS to use.)

Do you have a pointer to that discussion?

Are there other cases where netlib BLAS is considered more appropriate
than OpenBLAS because it’s more numerically stable?

Thanks for your feedback,
Ludo’.

Re: LAPACK vs. OpenBLAS

[Eric Brown]

Ludovic Courtès  writes:

> Hello!
> There are two cases:
>
>   1. Packages that depend on both ‘lapack’ and ‘openblas’.  This is
>  almost always a mistake because ‘openblas’ provides the same
>  interfaces as ‘lapack’, only with a more efficient implementation.
>
>   2. Packages that depend on ‘lapack’ only: for the same reason, they
>  should depend on ‘openblas’ instead.

My understanding is that Julia 1.6 (already released) requires 64-bit
BLAS, and openblas-ilp64 should do the trick.

There are scenarios where reference BLAS is more stable and/or
reproducible than optimized BLAS libraries.  Sometimes its lack of
knowledge of OpenBLAS and/or a numerical issue.

(cf. GNU R's discussion of which BLAS to use.)

Re: LAPACK vs. OpenBLAS

[zimoun]

Hi,

On Thu, 24 Jun 2021 at 14:55, Ludovic Courtès  wrote:

> Julia references both lapack and openblas:
>
> --8<---cut here---start->8---
> $ guix graph --path -t references julia lapack
> /gnu/store/d077a9ggqlcyhnhcg4ng2ibnlarxq8zf-julia-1.5.3
> /gnu/store/41rw9w35by4j8lbl85gi3xfiaf7zqykh-lapack-3.9.0
> $ guix graph --path -t references julia openblas
> /gnu/store/d077a9ggqlcyhnhcg4ng2ibnlarxq8zf-julia-1.5.3
> /gnu/store/bs9pl1f805ins80xaf4s3n35a0x2lyq3-openblas-0.3.9
> --8<---cut here---end--->8---
>
> Can a Julia-savvy person check whether this is justified?

I am not a Julia-savvy person, though I do not think it is justified.
I guess it comes from the requirements [1].  I am trying to remove
LAPACK and it could be part of the Julia v1.6 update, see [2].

1: 

2: 

Cheers,
simon