[arch-dev-public] Discussion - Increasing our CPU requirements

[Filipe Laíns]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20200329/abc9627e/attachment.sig>