Opened 9 months ago

Closed 8 months ago

#121 closed defect (fixed)

discontinue ThirdParty/Blas and Lapack

Reported by: stefan Owned by: stefan
Priority: major Component: build system
Version: trunk Keywords: autotools-update
Cc:

Description

I think of just forgetting about ThirdParty/Blas and ThirdParty/Lapack for the new setup, because I don't think it is so useful anymore:

  • Most Linux distributions bring blas and lapack with their package managers. It's often only the reference version (Netlib), but that's the same we were building anyway.
  • Mac OS X comes with (probably optimized) installations of Blas and Lapack in the Accelarate framework.
  • Msys2/MinGW on Windows seems to bring OpenBlas and Lapack with its package manager.
  • Intels MKL is available as community edition for free.
  • Building Blas and Lapack from source requires a Fortran compiler, which is extra work to be installed on Linux (easy), Mac OS X (possible), MinGW (relatively easy), Windows/MSVC (ifort costs money).
  • ThirdParty/Blas and Lapack was building only a subset of Blas and Lapack, which sometimes is not sufficient, requiring extra maintenance work. Also it is extra maintenance work (we do not even keep up with using the latest versions of the Netlib Lapack).

I would then also remove the f2c utility in BuildTools, for which I have no idea whether it is still working.

Change History (8)

comment:1 Changed 9 months ago by tkr

I definitely agree that this would reduce a lot of complexity. Getting rid of the need to look for a Fortran compiler would be awesome and simplify things. We should ask Brian Borchers about this, though. I think he said that the default versions of Blas and Lapack in many Linux distros are the reference implementation, which has very poor performance. It seems that maybe having ThirdParty packages that point to well-implemented versions of these would be good. We should make sure before we toss it out. Now that I understand the situation from Brian, I've definitely realized that we are better off without those packages in their current form, since they just pull the reference implementation.

Last edited 9 months ago by tkr (previous) (diff)

comment:2 Changed 9 months ago by stefan

The "well-implemented" version he refers to is OpenBlas. My ArchLinux has a package for this, so do Msys2 and Ubuntu. Thus, I would like to avoid setting up a ThirdParty for this.

The Accelerate framework on Mac OS X and Intel MKL should be optimized, too. I think we already did detect Accelerate on Mac OS X and MKL on Linux and Windows in the check for Blas. Some of this might not work with the current BuildTools/trunk, but that should be fixed up. Eventually, we should be able to find installations of reference Blas/Lapack, OpenBlas, and MKL on the three major platforms and find Accelerate on Mac OS X, libsunperf on Solaris, and libcomplib.sgimath on SGI (I just cite from coin.m4 for the last two). Some day one could also look for Atlas.

comment:3 Changed 9 months ago by tkr

OK, seems reasonable. I guess we just leave it there as a package but remove it as a dependency, right? By the way, I can't find anything about the Msys2 blas package on-line. Installing lapack as you did in the CoinUtils appveyor.yml works. I assume that somehow also provides blas? There is nothing listed here:

https://github.com/alexpux/msys2-packages

and that is the official list of packages, as far as I know.

comment:4 Changed 9 months ago by stefan

Yes, we would still need it as dependency for the "old" branches and releases. Maybe we can remove the branch "master" at some day.

Sorry, I tend to confuse Msys and MinGW. There is some openblas an lapack listed here: https://github.com/Alexpux/MINGW-packages

The MinGW/lapack package also includes a Blas library. They are DLLs, so I think the Lapack lib knows that also the Blas lib needs to be loaded. There are also blas.pc and lapack.pc files.

comment:5 Changed 9 months ago by tkr

Ah, OK, makes sense.

comment:6 Changed 9 months ago by lou

I've been poking at this on Fedora, and the situation here is that there are packages for lapack, blas, and openblas. The lapack package wants blas (not openblas). On the other hand, the packaged MUMPS wants openblas. It also seems to be the case that packaged blas libraries may include lapack (at least, there's a check for this in CHECK_PACKAGE_LAPACK in stable/0.8).

Details aside, I'm in favour of dropping the ThirdParty packages and modifying CHK_BLAS and CHK_LAPACK to look for an appropriate set of installed libraries. On linux systems, we probably want to go with something like [openblas blas]. People who are fussier can use configure command line parameters.

comment:7 Changed 8 months ago by stefan

While I originally thought that OpenBlas may also include Lapack, this isn't the case on my system (ArchLinux) at least. I've liblapack.so, libblas.so, and various libopenblas*.so. Currently, liblapack.so loads one of the libopenblas*.so, so the check for lapack.pc already gets openblas. If I were to remove the openblas package, I believe liblapack.so would (magically) load libblas.so instead.

So checking for OpenBlas in AC_COIN_CHK_LAPACK doesn't make much sense. I'm not sure yet whether we will still have need for an AC_COIN_CHK_BLAS (i.e., someone needs Blas but not Lapack), but that could then check for openblas before blas.

comment:8 Changed 8 months ago by stefan

  • Resolution set to fixed
  • Status changed from new to closed

Commits 3924 .. 3929 added more checks for optimized Lapack to AC_COIN_CHK_LAPACK and removed compile_f2c.

Note: See TracTickets for help on using tickets.