On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > > Hi Florian, > > On Mon, Jul 22, 2019 at 9:28 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: > > > > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update > > > > == Summary == > > Fedora currently uses the original K8 micro-architecture (without > > 3DNow! and other AMD-specific parts) as the baseline for its > > <code>x86_64</code> architecture. This baseline dates back to 2003 > > and has not been updated since. As a result, performance of Fedora is > > not as good as it could be on current CPUs. > > > > This change to update the micro-architecture level for the > > architecture to something more recent. > > > > == Owner == > > * Name: [[User:fweimer| Florian Weimer]] > > * Email: [mailto:fweimer@xxxxxxxxxx fweimer@xxxxxxxxxx] > > > > == Detailed Description == > > > > After preliminary discussions with CPU vendors, we propose AVX2 as the > > new baseline. AVX2 support was introduced into CPUs from 2013 to > > 2015. See [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2 > > CPUs with AVX2]. > > > > Along with AVX2, it makes sense to enable certain other CPU features > > which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and > > earlier vector extensions such as SSE 4.2. Details are still being > > worked out. > > It seems that Intel is still manufacturing CPUs without AVX support > (not even talking about AVX2) in 2019. So this is clearly no-go for > me. > > But I do want to see some refreshments in this area! There are > multiple options how to proceed I think: > > 1. Lower requirement to something like SSE4 and select other CPU > features which are available in most of CPUs for last decade. > 2. Build every package on x86_64 twice (one for compatible set and one > for this new-features set), possibly by introducting sub-architecture > in koji or using koji-shadow (that's just implementation detail. > Produce an official spin which is built from these packages. Thinking about this even more, it should not be very hard thing to do: * Define new architecture in RPM/libsolv (let's call it "haswell" or "x86_64modern") * Define set of capabilities it should have, write appropriate check in RPM/libdnf * Add new architecture in Fedora Koji * Once bootstrapped, create composes * At some point in future, merge this arch back to x86_64 and move forward What do you think? > 3. Invent some mechanism for selecting appropriate feature set in > runtime (somebody mentioned fat binaries in this thread). > > These options can be combined. > > > > > A test rebuild of a distribution largely based on Fedora 28 showed > > that there is only a small number of build failures due to the > > baseline switch. Very few packages are confused about the availability > > of the CMPXCHG16B instruction, leading to linking failures related to > > <code>-latomic</code>, and there are some hard-coded floating point > > results that could change due to vectorization. (The latter is within > > bounds of the usual cross-architecture variation for such tests.) > > > > == Benefit to Fedora == > > > > Fedora will use current CPUs more efficiently, increasing performance > > and reducing power consumption. > > > > Moreover, when Fedora is advertised as a distribution by a compute > > service provider, users can be certain that their AVX2-optimized > > software will run in this environment. > > > > == Scope == > > * Proposal owners: Update the <code>gcc</code> and > > <code>redhat-rpm-config</code> package to implement the new compiler > > flags. It is expected that the new baseline will be implemented in a > > new GCC <code>-march=</code> option for convenience. > > > > * Other developers: Other developers may have to adjust test suites > > which expect exact floating point results, and correct linking with > > <code>libatomic</code>. They will also have to upgrade their x86-64 > > machines to something that can execute AVX2 instructions. > > > > * Release engineering: [https://pagure.io/releng/issue/8513 #8513] > > ** All Fedora builders need to be AVX2-capable. > > ** Infrastructure ticket: > > [https://pagure.io/fedora-infrastructure/issue/7968 #7968] > > * Policies and guidelines: No guidelines need to be changed. > > * Trademark approval: N/A (not needed for this Change) > > > > == Upgrade/compatibility impact == > > Fedora installations on systems with CPUs which are not able to > > execute AVX2 instructions will not be able to upgrade. > > > > == How To Test == > > General system testing will provide test coverage for this change. > > > > == User Experience == > > User should observe improved performance and, likely, battery life. > > Developers will benefit from the knowledge that code with AVX2 > > optimizations will run wherever Fedora runs. > > > > == Dependencies == > > There are no direct dependencies on this change at this time. > > > > == Contingency Plan == > > It is possible to not implement this change, or implement a smaller > > subset of it (adopting the CMPXCHG16B instruction only, for example). > > > > * Contingency mechanism: Mass rebuild with different/previous compiler glags. > > * Contingency deadline: Final mass rebuild. > > * Blocks release? No. > > * Blocks product? No. > > > > == Documentation == > > The new micro-architecture baseline and the resulting requirements > > need to be documented. > > > > == Release Notes == > > Release notes must mention how users can determine whether their > > system supports AVX2 prior to upgrading, for example by running > > <code>grep avx2 /proc/cpuinfo</code>. > > > > -- > > Ben Cotton > > He / Him / His > > Fedora Program Manager > > Red Hat > > TZ=America/Indiana/Indianapolis > > _______________________________________________ > > devel-announce mailing list -- devel-announce@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-announce-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
