tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Advice on creating BLAS choice

On 04/30/18 10:02, Dr. Thomas Orgis wrote:
Hi there,

I finally would like to implement a generic BLAS choice. I imagine a
global variable specifying a default BLAS+LAPACK implementation to
choose. Using that, thre would be generic


that contain logic to make a package include e.g.


if GLOBAL_BLAS_DEFAULT=openblas_pthread. The is separate
to, although most BLAS choices also provide LAPACK, to keep the
dependencies cleaner. Also, one can imagine a separate
lapack-whateverblas package that combines reference netlib LAPACK with
a certain optimized BLAS. Anyhow … my first question is what is the
preferred way to implement such a global choice? I imagine

# any of: netlib atlas openblas openblas_pthread openblas_openmp

and mk/(blas|lapack) use that. Looking at
mk/, I tentatively would not introduce a
BLAS_ACCEPTED list for each package … the assumption is that any BLAS
works, unless it doesn't. So perhaps a BLAS_REFUSED would be more
fitting? Mind that the issues we talked about with especially parallel
BLAS variants being troublesome, the trouble usually covered certain
applications of installed packges, not the packages as such (certain
user-supplied R/Octave/Numpy scripts that may or may not cause trouble).

In case certain packages only work with certain BLAS, how would a
per-package override look? Define an additional variable BLAS_TYPE that
the package can set and which replaces BLAS_DEFAULT? Or is there
already standard trickery to override values per-package?
BLAS_DEFAULT.octave, like PKG_OPTIONS? I'm working with pkgsrc for some
time now, but a good part of my knowledge is still following the cargo

Then, I might want to cover the whole picture including the wrapper
libraries cblas and lapacke. A first step would one fixed decision (be
it default or override) for cblas and lapacke to use a certain
BLAS/LAPACK implementation and have any package that makes use of those
wrappers indirectly depend on the respective BLAS. One could imagine
creating variants of the wrapper libs for all BLAS implementations, but
one could also go out to chop trees with a toenail clipper.

Yeah, I hope it is fine when we focus on the case of one default
BLAS/LAPACK to use, also for the wrappers cblas and lapacke, with
certain packages that directly use a certain preferred BLAS being the
special case.

For now, I would like to have something to start with at all. I don't
see many cblas users around, anyway. Lapacke doesn't even exist (did I
miss it?). The situation I now aim for:

- BLAS_DEFAULT machinery with mk/ and
- math/cblas and math/lapacke packages (all pulled from lapack
   tarball to stay consistent), using BLAS_DEFAULT
- math/octave, math/R using BLAS_DEFAULT
- update of lapack to 3.8.0, but after everything else is in place and
   checking if our BLAS suppliers bundle the same version

Observe the last point: We need to ensure that every offered LAPACK
implementation agrees on the API. Version 3.8 adds things. If a BLAS
library does no timely updates in a certain timeframe, we should omit
the included LAPACK and make a library using netlib's LAPACK linked to
the optimized BLAS in pkgsrc. That either needs separate BLAS libs or
just some Makefile hackery to replace a supplied copy of LAPACK.

Now, can someone comment on the proper syntax approach before I start
copying stuff from other mk/*

Alrighty then,


PS: Please include my math/cgal patch (or equivalent) in CVS trunk … we
agreed long ago that the version bump is needed.

First comment:

From a social engineering standpoint, I would choose BLAS_REFUSED, or something else with a negative connotation, over BLAS_ACCEPTED.

As BLAS implementations are *supposed to be* compatible, I think we want something that looks like a red flag where any implementation doesn't work with a particular package.  Something that shouts FIXME.



Home | Main Index | Thread Index | Old Index