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

[Filipe Laíns]

On Sun, 2020-03-29 at 20:26 +1000, Allan McRae via arch-dev-public wrote:
> Remember when Arch Linux was optimized out of the box.   We have the
> blazingly fast i686 port while other distros hung out in i386 land.
> Those were the days where the idea of Arch being fast started.  Now it
> has degraded to stuff of legend.
> 
> Now, x86_64 is old.  We should continue to push forward and add further
> optimization.
> 
> Reasonable optimizations to consider:
> 
> AVX2
> FMA
> SSE4.2
> 
> AVX2 is Intel Haswell and newer or AMD Ryzen and newer.  This CPUs
> released 2013 to 2015.  So 5 - 7 years old.
> 
> Discuss.

Absolutely not!

A huge amount of systems do not meet that requirements. This would rule
out all Intel 3rd gen and older cpus, which would for eg. impact laptop
models such as the Thinkpad X220 and Thinkpad X230.

Instead of adding a requirement for newer CPU extensions let's fix this
the proper way.

The correct approach to this is to push upstreams to support dynamic
detection of CPU extensions. That means the performance critical code
is compiled with a different range of extensions and the binary detects
at runtime what to use. A lot of them do that already, and for the ones
which don't we should push for it (point them to [1]).

Unfortunately, we will always have upstreams that don't support that.
For this we should define a separate architecture. Right now I have
building 2 variants of the projects (see srslte-avx2 and liquid-dsp-
sse4.1), optimally we would have a different arch for them.

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.

There is only maybe a handful of packages in the repos that would
benefit from this.

[1] 
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-target_005fclones-function-attribute

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