Re: OpenBLAS and performance

[Eric Bavier <ericbavier@centurylink.net>]

On Wed, 20 Dec 2017 21:32:15 +0100
Pjotr Prins <pjotr.public12@thebird.nl> wrote:

> On Wed, Dec 20, 2017 at 09:00:46PM +0100, Ricardo Wurmus wrote:
> > > I do think we need to default to a conservative openblas for general
> > > use. Question is how we make it fly on dedicated hardware.  
> > 
> > Have you tried preloading the special library with LD_PRELOAD?  
> 
> It is not a question of what I can do. It is a question of how we give
> other people the benefit of optimized libs in an elegant way.

Related only to this specific case of BLAS libraries, and not to the
general idea of optimized libraries:

I recently discovered "FlexiBLAS" from the Max Planck Institute
https://www.mpi-magdeburg.mpg.de/projects/flexiblas which I thought
might be useful for Guix.  It lets one choose the desired BLAS backend
at runtime via a configuration file or environment variables. In it's
current state it needs a little configuration before use, but I think
with a little work we could make picking a BLAS implementation as easy
as, e.g.

  guix package -i python-numpy openblas-haswellp

or

  guix package -i python-numpy atlas-24

where the python-numpy package is the same in both cases, built with
a "flexiblas" input.

> Performance matters in some circles.

This should let people choose the BLAS implementation that is best for
their hardware/application.  It could also let Guix packages use
vendor-supplied BLAS libraries.

Just a thought,
`~Eric