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

Re: isa-support -- exit strategy?



On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote:
> On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote:
> > * while a hard Depends: works for leafy packages, on a library it
> >   disallows having alternate implementations that don't need the
> >   library in question.  Eg, libvectorscan5 blocks a program that
> >   uses it from just checking the regexes one by one.

> glibc 2.33 added a modernized version of the old hwcaps.
> If a package builds a library several times with different optimizations 
> and installs them into the correct directories in the binary package, 
> the dynamic linker will automatically select the fastest one supported 
> by the hardware.
> 
> SIMDe (or similar approaches) could be used to build variant(s) of the 
> library that have compile-time emulation of SIMD instructions in the 
> lower baseline builds of vectorscan.

In this particular case, it'd probably be faster to use non-SIMD ways
instead of emulating them.  This means two code paths, which particular
users may or may not want to do the effort to implement.

> For binaries, I have seen packages in the Debian Med (?) team that build 
> several variants of a program and have a tiny wrapper program that chooses
> the correct one at startup.

This may take substantial work to implement, which for typical Debian Med
packages is an utter waste of time.

I wonder why vectorscan requires SSE4.2 while hyperscan that it's a fork of
is happy with SSE3; a personal mail server may be perfectly adequate on
hardware lacking either -- but no SSE4.2 is still realistic while no SSE3
on amd64 requires some pretty specific dumpster diving (it's lacking only
on early steppings of Athlon 64).  Still, by our rules, SSE3 is not in the
arch baseline, thus it's a RC bug not to run without.

And thus, a Debian Med package is required to provide non-SSE3 builds that
are almost untestable without hard-to-get hardware, that's a pure waste of
maintainer time.

While that mail server may be fully happy with checking the patterns with
libpcre one by one.  What {vector,hyper}scan are good for is matching _many_
regexes on _many_ lines of data; if there's either few patterns or little
data, the serial slow way is as good or better.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Eight legs good, four legs bad! -- when your drider pwns a
⣾⠁⢠⠒⠀⣿⡁ smelly goodie centaur.
⢿⡄⠘⠷⠚⠋⠀ Rearkick OP -- my grandpa's brother-in-law got one-shotted
⠈⠳⣄⠀⠀⠀⠀ from full hp in RL, please nerf!


Reply to: