Re: GSoC project about binary packaging

[Michael Goffioul]

On Fri, Jun 21, 2013 at 5:02 PM, Jordi Gutiérrez Hermoso <address@hidden> wrote:

On 21 June 2013 16:43, John D <address@hidden> wrote:

> OpenBLAS seems to compile ok for native mingw compile, however might be a
> little flaky on cross builds? I have one linux computer that compiled it
> fine, another that did not – I hadn’t looked into why.

There's something I don't understand. Most BLASes try at compile time to
figure out what the optimal build flags are and how to produce the
best binary (e.g. which vector instructions the CPU supports, etc).
How can this work for distributing a compiled BLAS? Does the OpenBLAS
build know how to delegate these questions to runtime instead of
compile time?

OpenBLAS can be compiled in 2 modes: single-arch and dynamic-arch. In single-arch, you compile for a specific CPU family/chipset. There's no compile-time optimization involved like ATLAS, once a cpu/chipset is chosen, OpenBLAS is created out of a predefined set of highly optimized routines, mostly written in assembler. In dynamic-arch mode, all routines for all cpu/chipset are compiled and OpenBLAS then uses runtime CPU detection to select the set of routines to use. I suppose is a one-time detection at runtime.

In the past, I've compared multithreaded ATLAS and OpenBLAS under Windows on the architecture I had (Atom N470) and OpenBLAS outperformed ATLAS (not to mention that it compiles much faster than ATLAS).

 

> Also I haven’t looked at what speed differences/advantages there are
> in using openblas vs blas in octave

You mean vs ATLAS? We haven't shipped a reference BLAS with Octave for
a long time.

I have, in my MSVC binaries. The reference BLAS, though slow, is deemed to be more stable than OpenBLAS/ATLAS.

Michael.