* new installs fail quite late into installation process, leaving you
with a bunch of packages unpacked but unconfigured; some apt
frontends don't take this situation gracefully.
* upgrades when an existing package drops support for old hardware are
even worse.
* 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.
Suggestions?
Hi!
While packages are allowed to not support entire architectures
outright, there's a problem when some code requires a feature that is
not present in the arch's baseline. Effectively, this punishes an
arch
for keeping compatibility. The package's maintainers are then
required
to conform to the baseline even when this requires a significant work
and/or is a pointless exercise (eg. scientific number-crunching code
makes no sense to run on a 2002 box).
With that in mind, in 2017 I added "isa-support" which implements install-time checks via a dependency. Alas, this doesn't work as
well
as it should:
* new installs fail quite late into installation process, leaving you
with a bunch of packages unpacked but unconfigured; some apt
frontends don't take this situation gracefully.
* upgrades when an existing package drops support for old hardware
are
even worse.
* 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.
Suggestions?
Meow!
While packages are allowed to not support entire architecturesA partial arch (whatever that is, yeah) with the x86-64-v3 baseline, and optionally raise the main amd64 baseline to x86-64-v2?
outright, there's a problem when some code requires a feature that is
not present in the arch's baseline. Effectively, this punishes an arch
for keeping compatibility. The package's maintainers are then required
to conform to the baseline even when this requires a significant work
and/or is a pointless exercise (eg. scientific number-crunching code
makes no sense to run on a 2002 box).
With that in mind, in 2017 I added "isa-support" which implements install-time checks via a dependency. Alas, this doesn't work as well(that was expected tbh)
as it should:
Indeed supporting number crunching programs on ancient
hardware is not meaningful, but the demand on Debian's
support for number crunching is not that strong according
to my years of observation.
For popular applications that can take advantage of above-baseline instruction sets, they will eventually write the dynamic code
dispatcher and add the fallback.
For applications seriously need performance, they will
leave CPU and go to GPU or other hardware. If the user correctly
write the code and fully leverage GPU, the non-optimal CPU
code won't necessarily be a bottleneck.
For applications seriously need CPU performance, they are
possibly going to tell the users how to tweak compiling
parameters and how to compile locally.
A partial arch (whatever that is, yeah) with the x86-64-v3 baseline, and optionally raise the main amd64 baseline to x86-64-v2?
It might be worth looking at how things like Steam and Flatpak/Snap
solve this issue
I expect games and proprietary apps often use CPU
features unsupported on old systems.
I also wonder if qemu could be used to emulate newer CPU features on
older systems. That would probably be unusably slow though.
On Sat, Mar 26, 2022 at 2:36 AM M. Zhou <lumin@debian.org> wrote:
Indeed supporting number crunching programs on ancient
hardware is not meaningful, but the demand on Debian's
support for number crunching is not that strong according
to my years of observation.
For popular applications that can take advantage of above-baseline instruction sets, they will eventually write the dynamic code
dispatcher and add the fallback.
For applications seriously need performance, they will
leave CPU and go to GPU or other hardware. If the user correctly
write the code and fully leverage GPU, the non-optimal CPU
code won't necessarily be a bottleneck.
For applications seriously need CPU performance, they are
possibly going to tell the users how to tweak compiling
parameters and how to compile locally.
I have to disagree on this one. Yes, runtime detection and GPU
acceleration is great and all, but not every scientific library does
it and I think it's unrealistic for us to patch them all up.
Also I don't like the point "since there is low demand for number
crunching on Debian, so let's just continue to ignore this problem".
At least I know a decent amount of people that use Debian (or
downstream distros) for scientific number crunching. Compiling
optimized for large workloads will always be a thing no matter the
baseline, but when getting started distro packages are just one less
thing to care about.
On Sat, Mar 26, 2022 at 7:25 AM Andrey Rahmatullin <wrar@debian.org> wrote:
A partial arch (whatever that is, yeah) with the x86-64-v3 baseline, and optionally raise the main amd64 baseline to x86-64-v2?
+1
Hi!
...
* 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.
Suggestions?
Meow!
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.
On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote:
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.
But why? Who in their right mind would ever try to use those aweful
slow implementations?
On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote:
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.
But why? Who in their right mind would ever try to use those aweful
slow implementations?
Bastian
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.
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.
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.
...
Suggestions?
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:10:50 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,862 |