I want to clarify what I am proposing. I would not be an entirely new architecture in the sense of i686, CPU extensions are not different architectures and shouldn't be treated as such. What I would for us to do is to create a x86-64-axv2, etc. that would complement x86-64. We would not add it as a target for all packages, just for the ones that make sense. For this pacman would have to support architecture priority. We could have something like this: Architecture = x86-64-axv2 x86-64 This means if a x86-64-axv2 package is available, it would be selected over the x86-64 one. That way we don't need to rebuild all packages. My point here is that to me it does not really make sense to drop support for older CPUs. We will have little benefit in newer CPUs. Projects that need the performance already dynamically choose the CPU extensions to use in the runtime -- they will work on all x86-64 CPUs. If this did in fact bring a relevant performance improvement, like the original mail let's me to believe (but this may be just me), I would be all for it, but that's not the case. On Sun, 2020-03-29 at 16:51 +0200, Morten Linderud via arch-dev-public wrote:
Well, how do you think we supported two architectures? Why do you think `extra-x86_64-build` is named the way it is?
The "problem" is that we have no intentions of building 1 package 4 times and keep things in sync by hand, it was tedious enough with i686, which was part of why it was dropped in the first place. Thus we want build-servers to do this for us.
Then automate it? Is there any reason why we can't have the tooling build all architectures for us? Why not have an `extra-build` helper that will call extra-$arch-build for all every architecture? This will have practically the same affect as my SIMD packages not. The only difference would be how people are consuming them. It would just work out of the box instead of them having to install the -avx2 variant.
Allan is going to have a hard time argueing that the minimal improvements is going to justify the absurd time we'll end up building things by hand, it's the crux of the problem essentially. I'm also sure he knows this.
Surely we can bikeshed about which architectures to support, what we should discuss is how we should accomplish the task in general.
Furthermore, if you do indeed whish to move this forward please present us with reasonable data. Take a few packages that would benefit from this, build them with the proposed architecture and show us benchmarks. I think it's gonna be very hard for you to find packages with considerable improvement but I might be wrong, please show me.
See last paragraph.
Which paragraph are you referring to? I will be taking a step back now. I will probably wait 1 or 2 days before replying. Feel free to reach me privately for a direct discussion if you want to. Cheers, Filipe Laíns