On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
<ignatenkobrain(a)fedoraproject.org> wrote:
Hi Florian,
On Mon, Jul 22, 2019 at 9:28 PM Ben Cotton <bcotton(a)redhat.com> 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@redhat.com fweimer(a)redhat.com]
>
> == 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
> > 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@lists.fedora...