[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how best to package when using hardware vectorization with vector-unit specific code?



On 05/10/2017 11:52 AM, Wookey wrote:
> Debian requires packages to run on the base level ISA defined for each
> architecture (which does change slowly over time).

Well, kind of. What Debian requires is that if it is at all feasible
software should run on the base ISA - which in practice means that
very often the software is only compiled for the base ISA itself,
resulting in the binaries being slower than they need to be on more
modern hardware.

However, there are a couple of packages that can't easily be ported
to the base ISA (such as packages that use tons of SSE assembly,
which allows those packages to be run on some 32bit x86 CPUs), an
in this case the consensus was that it's better to have the packages
in Debian at all, even if they aren't available for all users. That
said, in those cases the basic constraints were that suitable
run-time checks need to be available to produce an error that the
user can understand (and not just fail with SIGILL), and to still
consider the fact that it doesn't run on the base ISA as a bug in the
package, just not a RC bug. (The rationale why this is not considered
RC is the following: take for example the case of SSE-assembly-heavy
code, which can't easily be made to work with x87 FPU-only systems.
If missing base ISA support in that case were to be RC, then the only
alternative would be to just drop i386 support completely, which is
a worse outcome because then nobody on i386 could use the package.)

With that all out of the way: if a package does support being
compiled for the base ISA, or a patch to make it work is trivial,
then it would be considered RC (on release archs at least) not
supporting the base ISA in the compiled package. What's not required
is to also compile optimized versions that run faster on newer
hardware - but in an ideal world one would also like to do that.
(With gcc's function multi-versioning (FMV) this has become a lot
easier noawadays though.)

Regards,
Christian


Reply to: