Dear mildly and wildly interested people in scientific computing,
hereby I present the plan and current realization regarding a
sensible handling of BLAS and LAPACK variants inside pkgsrc.
1. Present
==========
There is now a set of packages in wip that provide some BLAS+LAPACK:
????????wip/lapack: Netlib reference (libblas.so, liblapack.so)
????????wip/blas: a dummy that just depends on the above
????????wip/openblas: single-threaded OpenBLAS (libopenblas.so)
????????wip/openblas_pthread: threaded OpenBLAS (libopenblas_pthread.so)
????????wip/openblas_openmp: OpenMP OpenBLAS (libopenblas_openmp.so)
These packages are the first BLAS implementations I consider. Actually,
my goal ist to build all software relevant in our HPC installation with
parallel OpenBLAS (the pthread variant, currently). As a result of our
discussion on this list, you can install all of the variants in
parallel. It is recommened, though, to build all packages from pkgsrc
with a consistent choice of LAPACK and BLAS libraries.
The rule is that these do not conflict with each other an only provide
the Fortran libraries (BLAS and LAPACK functionality in a joined
library or separate ones). This explicitly excludes the C interfaces.
These are provided from the Netlib reference via the packages
????????wip/cblas: cblas.h and libcblas.so
????????wip/lapacke: lapacke.h and liblapacke.so
. They use the selected default BLAS and LAPACK implementation. There
are not that many well-known software packages using these, as far as I
know, but maybe there is a high count of end-user scientific software
that needs them.
I did not test wip/atlas. It should be easy to add to the list. The
only prerequisite is that it does not conflict with the C interfaces.
Including the BLAS C interface in the library may be OK, but at least
the header needs to go somplace else than include/cblas.h.
I added wip/mk/blas.buildlink3.mk to choose between the implementations
according to the value of BLAS_TYPE. Your choices are:
netlib ??? wip/lapack
openblas ??? wip/openblas
openblas_pthread ??? wip/openblas_pthread
openblas_openmp ??? wip/openblas_openmp
accelerate.framework ??? Accelerate framework on Darwin
There is also the possibility of setting BLAS_ACCEPTED with the ususal
semantics.
Any package depending on BLAS or full LAPACK is supposed to include
wip/mk/blas.buildlink3.mk and use the provided BLAS_LIBS and
LAPACK_LIBS to provide the values for the typically offered parameters
in build systems for the names of the libs. Complicated cases can of
course also use BLAS_TYPE directly for some branching.
2. Future
=========
In the end, I want to replace math/lapack and math/blas (which could
vanish in the long term) with the wip variants. I want to import the
openblas variants into math, and of course the central choice in
mk/blas.buildlink3.mk. Naturally, this should be a coordinated step.
Maybe math/atlas can be ready in time, too.
Until that is the case, I will convert the software that is of interest
to me to use wip/mk/blas.buildlink3.mk, probably pushing copies of it
to wip in the process. Currently, I do have local patches.
I do think a fast-track is possible and sensible, as at least
considering that the Netlib libraries stay the default that is used in
absence of a user setting BLAS_TYPE in mk.conf. I do not see a big risk.
The main change is an update of those from 3.7.1 to 3.8.0 and the
patches to packages are small and rather simplifying. The essence of
the changes in math/R is
+CONFIGURE_ARGS+=???????????? --with-blas=${BLAS_LIBS:Q}
+CONFIGURE_ARGS+=???????????? --with-lapack=${LAPACK_LIBS:Q}
+.include "../../mk/blas.buildlink3.mk"
and the removal of lines subsumed in blas.buildlink3.mk. My local patch
adds 7 lines and removes 21, while adding functionality in the form of
support for using OpenBLAS. I hope you understand that I would like to
avoid a longer waiting time for integration;-)
Once the stuff is imported to pkgsrc proper and packages converted to
use the central blas dependency, there is still some work to do. HPC
sites like my own usually do have also external providers of
accelerated libraries. One is MPI, where I never used the one provided
by pkgsrc, but am exercising the MPI_TYPE=native option I am adding
with a local patch (I think I posted it before without any result).
Another is BLAS support bundled with commercial compilers, namely the
Intel MKL.
I personally prefer Open Source software when possible, but performance
matters, and usually the commercial compilers and libraries have some
edge there, which is at least considerably reduced when using recent
GCC with OpenBLAS. This is where I came from, actually: Offer the Open
Source ecosystem via pkgsrc, with somewhat competetive performance
requires using an optimized BLAS. Hence, I started working on OpenBLAS
integration. For many users, this will be fine, the widest selection of
their frameworks with acceptable performance. Some users will rely on
things like MKL, and it would be good if pkgsrc can ease building a
software stack with that, too.
So, this is my plan. Any opinions? Is there a realistic option to push
some things into 2019Q1?
The new netlib packages are a version update to the existing software
and switch to the cmake build system, dropping lots of hackery around
the old Makefiles. But of course, it needs some testing on various
pkgsrc platforms. At least it is a really simple build devoid of any
non-trivial dependencies.
OK, one thing I just noticed: It might
The openblas packages are basically unchanged since over half a year in
wip now. I just did a version update.
I am awaiting some opinions before I start to spam wip with copies of
packages that have trivial patches. One example of such a change: commit
97aea744e8aa93887f9e7725073dd765478912f6 that updates suitesparse.
Actually, reviewing that one, I guess one can drop the patching of
SuiteSparse_config.mk; I just kept it as-is and changed the variables.
Alrighty then,
Thomas
PS: I do see an issue with wip/lapack only installing shared libraries,
while the other BLAS providers build both shared and static libs.
Anyone got a hint how to make a cmake-based package emit both?
Apparently one has to make two builds, with -DBUILD_SHARED_LIBS=ON and
-DBUILD_SHARED_LIBS=OFF. How to do that with the least cruft in
wip/lapack/Makefile.common?