Earlier quoted context omitted.
https://wiki.debian.org/ArchitectureVariants
Hm, discussion is from 2023. Did anything come out of it?
I believe it's just discussions right now. If/when something happens, I'm hoping they'll update the wiki.
Introducing architecture variants
81–90 of 152 posts
Re: Introducing architecture variants
#82What are the changes to dpkg and apt? Are they being shared with Debian? Could this be used to address the pesky armel vs. armel+hardfloat vs. armhf issue, or for that matter, the issue of i486 vs. i586 vs. i686 vs. the many varieties of MMX and SSE extensions for 32-bit? (There is some older text in the Debian Wiki https://wiki.debian.org/ArchitectureVariants but it's not clear if it's directly related to this effor…
Even if technically possible, it's unlikely this will be used to support any of the variants you mentioned in Debian. Both i386 and armel are effectively dead: i386 is reduced to a partial architecture only for backwards compatibility reasons, and armel has been removed entirely from development of the next release.
Re: Introducing architecture variants
#83Earlier quoted context omitted.
At least Intel and AMD have settled on a mutually supported subset of AVX-512 instructions.
The hard part was getting Intel and Intel to agree on which subset to keep supporting.
Even on the same chip.
Having a non-uniform instruction set for one package was a baffling decision.
Re: Introducing architecture variants
#84Earlier quoted context omitted.
> show that most packages show a slight (around 1%) performance improvement This takes me back to arguing with Gentoo users 20 years ago who insisted that compiling everything from source for their machine made everything faster. The consensus at the time was basically "theoretically, it's possible, but in practice, gcc isn't really doing much with the extra instructions anyway". Then there's stuff like glibc which h…
FWIW the cool thing about gentoo was the "use-flags", to enable/disable compile-time features in various packages. Build some apps with GTK or with just the command-line version, with libao or pulse-audio, etc. Nowadays some distro packages have "optional dependencies" and variants like foobar-cli and foobar-gui, but not nearly as comprehensive as Gentoo of course. Learning about some minor custom CFLAGS was just par…
I still use Gentoo for that reason, and I wish some of those principles around handling of optional dependencies were more popular in other Linux distros and package ecosystems.
There's lots of software applications out there whose official Docker images or pip wheels or whatever bundle everything under the sun to account for all the optional integrations the application has, and it's difficult to figure out which packages can be easily removed if we're not using the feature and which ones are load-bearing.
Re: Introducing architecture variants
#85Earlier quoted context omitted.
The hard part was getting Intel and Intel to agree on which subset to keep supporting.
Even on the same chip. Having a non-uniform instruction set for one package was a baffling decision.
I think that stemmed from their P-core design being shared between server and client. They needed AVX512 for server so they implemented it in the P-cores, and it worked fine there since their server chips are entirely P-cores or entirely E-cores, but client uses a mixture of both so they had to disable AVX512 to bring the instruction set into sync across both sides.
Re: Introducing architecture variants
#86Once they have rebuilt with rust, they get to move away from GPL licenses and get to monetize things.
Re: Introducing architecture variants
#87Earlier quoted context omitted.
The hard part was getting Intel and Intel to agree on which subset to keep supporting.
Even on the same chip. Having a non-uniform instruction set for one package was a baffling decision.
It’s a manifestation of Conway’s law: https://en.wikipedia.org/wiki/Conway%27s_law
They had two teams designing the two types of cores.
Re: Introducing architecture variants
#88What are the changes to dpkg and apt? Are they being shared with Debian? Could this be used to address the pesky armel vs. armel+hardfloat vs. armhf issue, or for that matter, the issue of i486 vs. i586 vs. i686 vs. the many varieties of MMX and SSE extensions for 32-bit? (There is some older text in the Debian Wiki https://wiki.debian.org/ArchitectureVariants but it's not clear if it's directly related to this effor…
This would allow mixing armel and softvfp ABIs, but not hard float ABIs, at least across compilation unit boundaries (that said, GCC never seems to optimize ABI bottlenecks within a compilation unit anyway)
Re: Introducing architecture variants
#89Announce was here: https://discourse.ubuntu.com/t/introducing-architecture-vari... and key point: "Previous benchmarks we have run (where we rebuilt the entire archive for x86-64-v3 57) show that most packages show a slight (around 1%) performance improvement and some packages, mostly those that are somewhat numerical in nature, improve more than that."
Are there any use cases where that 1% is worth any hassle whatsoever?
They did say some packages were more. I bet some are 5%, maybe 10 or 15. Maybe more.
Well one example could be llama.cpp . It's critical for them to use every single extension the CPU has move more bits at a time. When I installed it I had to compile it.
This might make it more practical to start offering OS packages for things like llama.cpp
I guess people that don't have newer hardware aren't trying to install those packages. But maybe the idea is that packages should not break on certain hardware.
Blender might be another one like that which really needs the extensions for many things. But maybe you so want to allow it to be used on some oldish hardware anyway because it still has uses that are valid on those machines.
Re: Introducing architecture variants
#90[dead]