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

[Filipe Laíns]

On Mon, 2020-03-30 at 09:07 +1000, Allan McRae via arch-dev-public wrote:
> 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?

I was looking at some edge cases where the CPUs had AVX but no SSE4.2.
Intel's website is also a bit unreliable with older CPUs, a lot of the
cases it is not listing extensions when it should be.

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

Right, that works too. Although, we can't have the word "auto" in the
arch definition automatically identifying and enabling the supported
extensions.

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

Well. The thing about these CPU extensions is that they require very
specific use workloads to be useful. They are more efficient when
performing the tasks they were design to do, but they have an higher
power consumption, which generally results in the CPU lowering clocks.
To make proper use of them, you usually need to build your algorithm
around them.

Just enabling it in GCC might bring some performance improvements but
they are usually *very* minimal.

Upstreams that benefit from these extensions will most of the time
write their own kernels and provide runtime detection or add a switch
in the build system.

I don't believe this is too much of burden for packagers. 99.9% of the
time, just building a package with SEE/AVX natively in GCC will not
bring any relevant performance enhancement.

Furthermore, building an extra optimized version makes it much more
reasonable for us to choose AVX2, which will have a much higher real
world impact than just building everything with SSE4.2 instead.

With that said, if you still want to bump the minimum requirements,
could please consider taking just a little bit of time to run some
benchmarks on packages you think should get an improvement?

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

The instruction set might be 10 years old, but you have to look at the
discontinuation date for CPU families which don't support it, and maybe
add 1 or 2 years for the bulk of the inventory to be cleared out from
stores.

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/20200330/41126e64/attachment.sig>