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