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

[Allan McRae]

On 30/3/20 12:39 am, Filipe Laíns wrote:
> 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.


SSE4.2 is 2008 for Intel, 2011 for AMD.  Though I guess some processors
were released without it for some time after that.   AVX was released by
both in 2011.

So why is one too far and the other not?


>> 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.

No need for pacman support.  Just add higher instruction set to a new
repo and set that repo with higher priority.

But that involves developers choosing which packages to build with
higher instruction sets, which requires extra developer time.

Ideally, we would just autobuild for more optimized architectures, but
this requires auto-signing packages, which has not happened in the last
decade (but may in this one...).


Picking an instruction set that is ~10 years old and making it the
default for the distro seems a reasonable approach to me.

A