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