FYI, we've managed to narrow down the issue to this:
https://github.com/xianyi/OpenBLAS/issues/2839
On Tue, 15 Sep 2020 at 12:22, Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
I found that this may be a packaging issue in openblas. What I did was
to download the source distribution, then
$ tar xf openblas-0.3.10.tar.gz
$ cd OpenBLAS-0.3.10
$ make USE_THREAD=1 USE_OPENMP=1
$ CMD='octave -H -q --no-window-system --no-site-file --eval
pkg("load","statistics");test("/usr/share/octave/pac
kages/statistics-1.4.1/canoncorr.m");'
$ FLEXIBLAS=$PWD/libopenblas.so $CMD
PASSES 7 out of 7 tests
My guess is that the spec requires a "make clean" between builds with
different flags. Makes sense?
Iñaki
On Fri, 4 Sep 2020 at 11:22, Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
>
> On Fri, 4 Sep 2020 at 11:16, Susi Lehtola
> <jussilehtola(a)fedoraproject.org> wrote:
> >
> > On Fri, 4 Sep 2020 10:57:13 +0200
> > Iñaki Ucar <iucar(a)fedoraproject.org> wrote:
> > > Hi,
> > >
> > > Strange... Let me bring this upstream to see whether this is
> > > flexiblas' or openblas' fault. In the meanwhile, exporting
> > > FLEXIBLAS=netlib before the tests makes use of the reference
> > > implementation, so everything should be slower but safer. And if this
> > > starts happening in the wild, we can change to openblas-serial with a
> > > quick update of FlexiBLAS.
> >
> > ... which would lead to a horrendous regression in performance, utterly
> > ruining parallellization.
> >
> > If this happens, there is no alternative but to resort to the
> > contingency plan of the FlexiBLAS as BLAS/LAPACK manager: undo all
> > changes and rebuild all packages so that they work again as intended.
>
> If this is a bug in FlexiBLAS, by experience I'm sure it will be fixed
> soon. If not, then it's a bug in openblaso, which should be also
> tracked down and fixed; otherwise, would you link packages back to
> openblaso knowing it's faulty?
>
> --
> Iñaki Úcar
--
Iñaki Úcar
--
Iñaki Úcar