Re: OpenBLAS and performance

[Dave Love <fx@gnu.org>]

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Pjotr,
>
>> I was just stating that the default openblas package does not perform
>> well (it is single threaded, for one).
>
> Is it really single-threaded?  I remember having a couple of problems
> with OpenBLAS on our cluster when it is used with Numpy as both would
> spawn lots of threads.  The solution was to limit OpenBLAS to at most
> two threads.

Yes, it's symlinked from the libopenblasp variant, which is linked
against libpthread, and I'd expect such problems.

Anyhow, there's something badly wrong if it doesn't perform roughly
equivalently to MKL on SIMD other than AVX512.  If I recall correctly,
the DGEMM single-threaded performance/core for HPC-type Sandybridge is
in the high 20s GFLOPs, and roughly double that for avx2
({Has,broad}well).  I don't think the bad L2 cache value that currently
used for Haswell has much effect in that case, but does in other
benchmarks.  I'll supply a patch for that.

Another point about the OB package is that it excludes LAPACK for some
reason that doesn't seem to be recorded.  I think that should be
included, partly for convenience, and partly because it optimizes some
of LAPACK.