setup-fortran icon indicating copy to clipboard operation
setup-fortran copied to clipboard

LAPACK and BLAS Support

Open gha3mi opened this issue 1 year ago • 9 comments

Hi, I am thinking on adding support for certain libraries to setup-fortran, especially LAPACK and BLAS. Do you think setup-fortran is the right place for this?

gha3mi avatar Jan 14 '24 22:01 gha3mi

While I see the appeal I wonder about scope/complexity creep. Maybe best limited to BLAS/LAPACK if we pursue this?

One question is which versions, presumably not the unoptimized reference. For Intel there is MKL. openBLAS seems like the typical choice otherwise and is available on APT, homebrew, mingw. However I think optimized blas/lapack are already built into macOS in the Accelerate framework.

There are also questions of GPU support. GitHub just opened private beta for hosted GPU runners https://github.com/github/roadmap/issues/505 not to mention self-hosting. I guess we would detect platform and pick from cublas, rocblas, etc but I don't have any sense of the difficulty/overhead of installation, and there are also e.g. CLBlast.. I am out of my depth here, maybe others can weigh in.

wpbonelli avatar Jan 15 '24 16:01 wpbonelli

I've been thinking about making libraries with fpm, which I used for ForLAPACK and ForBLAS. These may not be optimized versions, but for testing Fortran codes on GitHub, it could be a straightforward approach.

There are also questions of GPU support. GitHub just opened private beta for hosted GPU runners github/roadmap#505 not to mention self-hosting. I guess we would detect platform and pick from cublas, rocblas, etc but I don't have any sense of the difficulty/overhead of installation, and there are also e.g. CLBlast.. I am out of my depth here, maybe others can weigh in.

Interesting!

gha3mi avatar Jan 16 '24 09:01 gha3mi

I created a fork that also installs mkl libraries for ubuntu and macos. https://github.com/ssciwr/setup-fortran

Will also open a PR so that it may get merged with this action.

iulusoy avatar Mar 11 '24 13:03 iulusoy

@iulusoy I took a quick look at your fork. I like the idea, but I wonder if worth the effort. If we do this, I think it should be generic and support arbitrary components from Base or HPC kit, rather than separate inputs for each component like install_mkl. For instance we have a request to setup MPI too #21.

Maybe something like intel_components, which could accept a delimited list of the name segments following intel.oneapi.<platform>. e.g. mkl.devel,mpi,dnnl, and translate this into the full component names (retrievable from the installer with --list-components). However I am not sure component names are consistent across all versions. The action would also need to maintain a mapping of which are in base/hpc kit.

Or even more generic, maybe booleans like

- uses: fortran-lang/setup-fortran@v1
   id: setup-fortran
   with:
      compiler: ...
      version: ...
      math: true
      mpi: true

...where math installs mkl for intel and some other blas/lapack for other toolchains, and similar for mpi.

This could get pretty complicated and I want to avoid inconsistent/adhoc solutions if possible. I'm tempted to say if someone needs mkl/mpi/etc, better off just writing a custom workflow. Maybe @awvwgk has thoughts

wpbonelli avatar Mar 11 '24 14:03 wpbonelli

Thank you for your feedback @wpbonelli. True, it would be nice to have something more generic.

I set it up just for mkl because I just needed those libraries, and tried to generalize for as many versions on macOS as possible. Since the code I am working with is not tested on windows, I skipped that.

It would be fairly easy to create a general action for mkl and mpi just on linux without introducing too much complexity in the code.

iulusoy avatar Mar 12 '24 07:03 iulusoy

@iulusoy my bandwidth to work on this is limited but please feel free if you and/or @gha3mi want to push this forward. In general I think it's probably best to

  • support all three platforms
  • include all currently supported toolchain versions
  • avoid toolchain-specific inputs if possible

but happy to take a look at any PR. Thanks for the contributions!

wpbonelli avatar Mar 12 '24 14:03 wpbonelli

A modernized reference BLAS/LAPACK just went into stdlib — perhaps we could add a separate option to install the stdlib

wpbonelli avatar Apr 12 '24 23:04 wpbonelli

I'm in the process of modernizing an old MKL repo and am frustrated by windows + intel-fortran.

I understand your concern about scope creep, but I don't understand why a user would want to use IFX if not for the libraries it traditionally bundles. And given the particulars of the msvc linker and its demands of "our tooling is too complicated for you to simply edit the INCLUDE path yourself, you better run this environment setup script", these factors sort've conspire to make your action larger by necessity.

Anyways, for my part, I'm not sure exactly what I'm going to do, I think my plan will be to put the fortran-essentials installer somewhere and simply invoke it on every build. This is a slow approach but it should work well enough.

Please add support for the intel libraries to ifx; or alternatively kick ifx out of this action and make a custom action dedicated entirely to ifx & oneAPI.

Groostav avatar May 15 '25 00:05 Groostav

Does the math branch meet your needs? See #81.

Please add support for the intel libraries to ifx; or alternatively kick ifx out of this action and make a custom action dedicated entirely to ifx & oneAPI.

Contributions welcome. See also https://github.com/rscohn2/setup-oneapi

wpbonelli avatar May 15 '25 03:05 wpbonelli