Re: OpenBLAS and performance

[Pjotr Prins <pjotr.public12@thebird.nl>]

On Thu, Dec 21, 2017 at 12:02:55AM +0100, Ricardo Wurmus wrote:
> 
> Pjotr Prins <pjotr.public12@thebird.nl> writes:
> 
> > 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.
> 
> I’m asking because preloading different BLAS libraries is a thing.  If
> this works then we can ask people to just pick their favourite BLAS
> library variant and preload it.  We don’t need to build all combinations
> of library variants and applications.

Ah, sorry, I misunderstood. Let me play with that a little. Do note
that it is a bit more complex than it looks. For example, often you
need a cblas API. This comes with gslclas and openblas built-in. So,
to use atlas you also need libgslcblas.so. With optimized openblas you
don't.

> > I think channels actually should make a difference if we don't cater
> > in default Guix for such use cases.
> 
> I think channels (and really: alternative build farms) do make sense for
> tuned builds.

+1. The use case is simply:

  guix channel pjotr-optimized-haswell
  guix package -i python-numpy

which would install my optimized edition.

Pj.