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-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
