Bug#963250: openblas: Please build on armel

[Mo Zhou]

Hi,

I second that enabling openblas on armel makes basically no sense.
If you want a BLAS implementation that is possibly slightly faster than
the standard src:lapack, please try using src:blis instead of
src:openblas on armel, since src:blis contains some generic
optimizations.

On Sun, Jun 21, 2020 at 07:33:21PM +0200, Sébastien Villemot wrote:
> Le dimanche 21 juin 2020 à 17:28 +0300, Adrian Bunk a écrit :
> > On Sun, Jun 21, 2020 at 02:54:22PM +0200, Sébastien Villemot wrote:
> > > Le dimanche 21 juin 2020 à 14:40 +0300, Adrian Bunk a écrit :
> > > > Source: openblas
> > > > Version: 0.3.9+ds-2
> > > > Severity: normal
> > > > Tags: patch
> > > > 
> > > > A debdiff for building openblas on armel is attached.
> > > 
> > > What’s the point of building openblas on armel? 
> > > 
> > > Openblas is a highly optimized BLAS library, which only makes sense on
> > > machines with hardware floating point.
> > > 
> > > For armel, reference BLAS (as provided by src:lapack) is probably as
> > > efficient.
> > 
> > I don't think "efficiency" is relevant when using either on armel hardware...
> 
> Sure. But the difference is that src:lapack is standard Fortran 77, and
> should thus be well supported on armel. On the contrary, src:openblas
> is full of hardware-specific hacks, assembly code and the like; and
> upstream does not support armel.
> 
> So enabling it on armel could mislead users into believing that
> openblas is supported and/or useful on their platform, which it is not.
> 
> Also, upstream will not help us if there is a regression, and the
> package is likely to take forever to build given the low performance of
> armel (building it is already very resource hungry on an recent amd64
> machine).

Y.
 
> > What I am interested in is that reverse dependencies behave 
> > (and break) the same on armel as they do on armhf.
> 
> Note that since src:lapack and src:openblas provide the same ABI, the
> recommended practice for packagers is to never explicitly (build-
> )depend on openblas (or at most to put it second in an alternative, or
> as a Recommends).
> 
> But in any case, I don’t understand why we should aim at identical
> behaviour of armel and armhf in the field of number crunching. Those
> two architectures are very different in that area, in a number of
> respects, and this is unavoidable given the hardware differences.

We should not expect the same bahaviour of hardware floating point
calculation from software-emulated float point operations.
 
> So I personally see more inconvenients than advantages to implementing
> this.
> 
> Maybe my co-maintainer Mo Zhou could weigh in?
 
* If the reverse dependency must use openblas, then please disable the
  reverse dependency on armel. Nobody sane does numerical calculation on
  armel.

* If the standard src:lapack is too slow, please try the alternative
  src:blis instead of src:openblas.

> -- 
> ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
> ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
> ⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
> ⠈⠳⣄⠀⠀⠀⠀  https://www.debian.org
> 



> -- 
> debian-science-maintainers mailing list
> debian-science-maintainers at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers