Using OpenBLAS for Octave.app

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Using OpenBLAS for Octave.app

apjanke-floss
Hi, Octave maintainers,

Currently, Octave.app (the "native" Mac app distribution of GNU Octave
that Sebastian and I run, http://octave-app.org/) uses Apple Accelerate
for its BLAS and LAPACK implementations. This is mostly because
Octave.app is built on Homebrew, and Homebrew prefers to use Apple
system-provided libraries wherever feasible.

We're thinking of switching over to use OpenBLAS instead.
(https://github.com/octave-app/octave-app/issues/118) My thinking is this:

Advantages to using OpenBLAS:

1. Academic and scientific audiences may prefer OpenBLAS, since the
ethos of reproducible research demands open software throughout the stack.
2. Would make Octave behavior more consistent between platforms, since
Linux and Windows Octave users are already using OpenBLAS, and this
would make our Mac Octave match their behavior
   a. Would help with testing, since now the Linux/Windows and Mac
native app Octave user bases would be using & testing the same
underlying library.
   b. Would fix a couple annoying test failures on Mac.

Advantages to using Accelerate:

1. Somewhat simpler build process
2. Consistent with Homebrew, which is a big install base
3. ???

I think the arguments for OpenBLAS here really outweigh the arguments
for Accelerate. (And maybe we could even talk core Homebrew into
switching over.)

Do any of y'all have opinions on this? Especially from someone who
actually knows about BLAS and scientific/research programming?

Is there an official core Octave position on which BLAS
implementation(s) are preferred for use with Octave?

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Using OpenBLAS for Octave.app

Colin Macdonald-2
On 2019-10-21 12:05 p.m., Andrew Janke wrote:
> Advantages to using Accelerate:
>
> 1. Somewhat simpler build process
> 2. Consistent with Homebrew, which is a big install base
> 3. ???
 >
> Do any of y'all have opinions on this? Especially from someone who
> actually knows about BLAS and scientific/research programming?

I'm not in this category.  But its possible that using vendor-specific
BLAS can give performance improvements on specific hardware.

No particular opinion about whether its worth it: just something to add
to point 3. above.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Using OpenBLAS for Octave.app

Marius Schamschula-5
In reply to this post by apjanke-floss
I can’t say I have any more insights about the technical benefits of one implementation or another.

However, until Apple started playing with kernel timing several macOS versions ago, all my octave installs used Atlas. Now Atlas is useless under macOS.

If I recall correctly, Accelerate Framework has had some technical issues (i.e. erroneous results) in the past. I don’t know if these have been fixed.

OpenBLAS is a variant under MacPorts, though the default variant (and thus the pre-compiled package) uses the Accelerate Framework.

Marius
--
Marius Schamschula




On Oct 21, 2019, at 2:05 PM, Andrew Janke <[hidden email]> wrote:

Hi, Octave maintainers,

Currently, Octave.app (the "native" Mac app distribution of GNU Octave that Sebastian and I run, http://octave-app.org/) uses Apple Accelerate for its BLAS and LAPACK implementations. This is mostly because Octave.app is built on Homebrew, and Homebrew prefers to use Apple system-provided libraries wherever feasible.

We're thinking of switching over to use OpenBLAS instead. (https://github.com/octave-app/octave-app/issues/118) My thinking is this:

Advantages to using OpenBLAS:

1. Academic and scientific audiences may prefer OpenBLAS, since the ethos of reproducible research demands open software throughout the stack.
2. Would make Octave behavior more consistent between platforms, since Linux and Windows Octave users are already using OpenBLAS, and this would make our Mac Octave match their behavior
 a. Would help with testing, since now the Linux/Windows and Mac native app Octave user bases would be using & testing the same underlying library.
 b. Would fix a couple annoying test failures on Mac.

Advantages to using Accelerate:

1. Somewhat simpler build process
2. Consistent with Homebrew, which is a big install base
3. ???

I think the arguments for OpenBLAS here really outweigh the arguments for Accelerate. (And maybe we could even talk core Homebrew into switching over.)

Do any of y'all have opinions on this? Especially from someone who actually knows about BLAS and scientific/research programming?

Is there an official core Octave position on which BLAS implementation(s) are preferred for use with Octave?

Cheers,
Andrew


Reply | Threaded
Open this post in threaded view
|

Re: Using OpenBLAS for Octave.app

apjanke-floss

On 10/21/19 7:48 PM, Marius Schamschula wrote:

>> On Oct 21, 2019, at 2:05 PM, Andrew Janke <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Hi, Octave maintainers,
>>
>> [...snip...]
>>
>
> I can’t say I have any more insights about the technical benefits of one
> implementation or another.
>
> However, until Apple started playing with kernel timing several macOS
> versions ago, all my octave installs used Atlas. Now Atlas is useless
> under macOS.

I didn't know about this! Is there anywhere I can read about it?

> If I recall correctly, Accelerate Framework has had some technical
> issues (i.e. erroneous results) in the past. I don’t know if these have
> been fixed.

There are some nagging test failures that happen under Apple Accelerate
but not under OpenBLAS. They have not been fixed AFAIK, nor are likely
to be.

> OpenBLAS is a variant under MacPorts, though the default variant (and
> thus the pre-compiled package) uses the Accelerate Framework.

I'm afraid Octave.app has no space for variants: our goal is to provide
a super-simple one-step drag-and-drop install for Octave on Mac. So
we're interested in deciding the Right way to do this, instead of
providing users options.

As I understand it, BLAS is actually a run-time "pluggable" thing: code
compiles against the BLAS API and not a particular implementation, and
then you can (in theory) drop in any conformant implementation library
at load & run time. But I don't know of a good mechanism for switching
between BLAS implementations, especially for a "double-click to open"
Mac GUI app like Octave.app, where you can't inherit environment
variables (like LD_PRELOAD/DYLD_INSERT_LIBRARIES) from a shell.

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Using OpenBLAS for Octave.app

Marius Schamschula-5

Marius
--
Marius Schamschula




On Oct 21, 2019, at 7:11 PM, Andrew Janke <[hidden email]> wrote:


On 10/21/19 7:48 PM, Marius Schamschula wrote:

On Oct 21, 2019, at 2:05 PM, Andrew Janke <[hidden email]
<[hidden email]>> wrote:

Hi, Octave maintainers,

[...snip...]


I can’t say I have any more insights about the technical benefits of one
implementation or another.

However, until Apple started playing with kernel timing several macOS
versions ago, all my octave installs used Atlas. Now Atlas is useless
under macOS.

I didn't know about this! Is there anywhere I can read about it?


If I recall correctly, Accelerate Framework has had some technical
issues (i.e. erroneous results) in the past. I don’t know if these have
been fixed.

There are some nagging test failures that happen under Apple Accelerate
but not under OpenBLAS. They have not been fixed AFAIK, nor are likely
to be.

OpenBLAS is a variant under MacPorts, though the default variant (and
thus the pre-compiled package) uses the Accelerate Framework.

I'm afraid Octave.app has no space for variants: our goal is to provide
a super-simple one-step drag-and-drop install for Octave on Mac. So
we're interested in deciding the Right way to do this, instead of
providing users options.

That wasn’t my intention. I was pointing out that this combination has been tested.
I personally have installed it a the cost of having to build it locally (and every time there is a revision or upstream update).

As I understand it, BLAS is actually a run-time "pluggable" thing: code
compiles against the BLAS API and not a particular implementation, and
then you can (in theory) drop in any conformant implementation library
at load & run time. But I don't know of a good mechanism for switching
between BLAS implementations, especially for a "double-click to open"
Mac GUI app like Octave.app, where you can't inherit environment
variables (like LD_PRELOAD/DYLD_INSERT_LIBRARIES) from a shell.

Cheers,
Andrew

Reply | Threaded
Open this post in threaded view
|

Re: Using OpenBLAS for Octave.app

apjanke-floss


On 10/21/19 8:30 PM, Marius Schamschula wrote:

>
>> On Oct 21, 2019, at 7:11 PM, Andrew Janke <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>
>> On 10/21/19 7:48 PM, Marius Schamschula wrote:
>>> However, until Apple started playing with kernel timing several macOS
>>> versions ago, all my octave installs used Atlas. Now Atlas is useless
>>> under macOS.
>>
>> I didn't know about this! Is there anywhere I can read about it?
>
> See: https://trac.macports.org/ticket/54342

Thanks! That's what I needed.

>>> If I recall correctly, Accelerate Framework has had some technical
>>> issues (i.e. erroneous results) in the past. I don’t know if these have
>>> been fixed.
>>
>> There are some nagging test failures that happen under Apple Accelerate
>> but not under OpenBLAS. They have not been fixed AFAIK, nor are likely
>> to be.
>>
>>> OpenBLAS is a variant under MacPorts, though the default variant (and
>>> thus the pre-compiled package) uses the Accelerate Framework.
>>
>> I'm afraid Octave.app has no space for variants: our goal is to provide
>> a super-simple one-step drag-and-drop install for Octave on Mac. So
>> we're interested in deciding the Right way to do this, instead of
>> providing users options.
>
> That wasn’t my intention. I was pointing out that this combination has
> been tested.
> I personally have installed it a the cost of having to build it locally
> (and every time there is a revision or upstream update).

Oh! Understood. That makes sense.

And an FYI for folks: I found out that core Homebrew switched to using
OpenBLAS for all their BLAS needs, including for Octave, earlier this
year. Other Mac scientific computing packages seem to be heading that
way, too.

https://github.com/octave-app/octave-app/issues/118#issuecomment-545588676

So I'm pretty sure Octave.app will make the switch too.

Cheers,
Andrew