LAPACK vs. OpenBLAS

LAPACK vs. OpenBLAS

[Ludovic Courtès]

Hello!

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

--8<---------------cut here---------------start------------->8---
$ guix refresh -l lapack
Building the following 261 packages would ensure 614 dependent packages are rebuilt: […]
--8<---------------cut here---------------end--------------->8---

Among them are Julia and Octave.  You can see the reverse dependency
graph with:

  guix graph -t reverse-bag lapack | xdot -

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.

I’ve addressed a case like #1 for numpy/scipy in
6623d1cd7f3298f2e5c224299d11a77f7ae18bf5, and #2 with commit
c7a5c3e0bba2ac3d197b219d21527863308b75dd (petsc).

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’ll look at some of the other cases.  Perhaps we could have a lint
checker warning against the use of lapack.

Thoughts?

Thanks,
Ludo’.

Re: LAPACK vs. OpenBLAS

[zimoun]

Hi,

On Thu, 24 Jun 2021 at 14:55, Ludovic Courtès <ludovic.courtes@inria.fr> 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: <https://github.com/JuliaLang/julia/blob/master/doc/build/build.md#required-build-tools-and-external-libraries>
2: <http://issues.guix.gnu.org/issue/48325>

Cheers,
simon

Re: LAPACK vs. OpenBLAS

[Eric Brown]

Ludovic Courtès <ludovic.courtes@inria.fr> 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

[Ludovic Courtès]

Hi Eric,

Eric Brown <ecbrown@ericcbrown.com> 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]

Hi Ludo'!

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

> Hi Eric,
>
> Eric Brown <ecbrown@ericcbrown.com> 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

[Eric Brown]

Ludovic Courtès <ludovic.courtes@inria.fr> writes:

> Hi Eric,
>
> Eric Brown <ecbrown@ericcbrown.com> 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

[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/