search

coin-or-tools / BuildTools

Macros and patches for GNU autotools
https://coin-or-tools.github.io/BuildTools/
Other
3 stars 7 forks source link

discontinue ThirdParty/Blas and Lapack #121

Closed svigerske closed 5 years ago

svigerske commented 5 years ago

Issue created by migration from Trac.

Original creator: @svigerske

Original creation time: 2018-10-28 15:06:36

Assignee: @svigerske

Keywords: autotools-update

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:

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

svigerske commented 5 years ago

Comment by @tkralphs created at 2018-10-28 16:48:28

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.

svigerske commented 5 years ago

Comment by @svigerske created at 2018-10-28 18:23:05

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.

svigerske commented 5 years ago

Comment by @tkralphs created at 2018-10-29 14:04:30

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.

svigerske commented 5 years ago

Comment by @svigerske created at 2018-10-29 14:20:38

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.

svigerske commented 5 years ago

Comment by @tkralphs created at 2018-10-29 16:08:15

Ah, OK, makes sense.

svigerske commented 5 years ago

Comment by @LouHafer created at 2018-11-01 19:03:44

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.

svigerske commented 5 years ago

Comment by @svigerske created at 2018-11-24 13:38:59

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.

svigerske commented 5 years ago

Comment by @svigerske created at 2018-11-24 13:42:38

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

svigerske commented 5 years ago

Comment by @svigerske created at 2018-11-24 13:42:38

Resolution: fixed