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

[Filipe Laíns]

On Sun, 2020-03-29 at 23:37 +1000, Allan McRae via arch-dev-public wrote:
> On 29/3/20 11:17 pm, Filipe Laíns wrote:
> > I would also like to note that rebuilding everything with forced
> > support for AVX2 or whatever won't have much effect. Most packages do
> > not have workloads where it would make use sense to use these CPU
> > extensions, and as such, GCC would not use them.
> 
> That assumes we just add AVX2.  Whereas, requiring a CPU supporting AVX2
> would bring other optimizations that would be used.

No, it should be true for all extensions.

> As I replied earlier, AVX2 may be going too far.  But is a good starting
> point for discussion.  If that is too far, what could we accept?
> SSE4.2?  AVX?   Surely we can do better than pure x86_64.

No, SSE4.2 is too far. For me, the minimum should be AVX.

> To have a separate architecture would require automated builds, which
> requires being able to sign packages automatically.  And we have not
> achieved database signing in 9 years....  I'm looking for a boost that
> could be achieved now.

No, it would not. Where is this coming from? I already build split
packages with SIMD instructions, I make the PKGBUILD build for 2
architectures instead with a minimal patch.

If pacman is not able to handle parallel architectures, we should fix
that. I think it's a valid use case.

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.

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/7e0c4b4a/attachment.sig>