Le mar. 23 juil. 2019 à 08:30, Igor Gnatenko
<ignatenkobrain(a)fedoraproject.org> a écrit :
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")
x86_64avx2 ? or even avx2 ?
* Define set of capabilities it should have, write appropriate check
in RPM/libdnf
* Add new architecture in Fedora Koji
Do we really need a whole separate
architecture ? I expect that
enabling few selected packages to have a second (a third) optimized
build will be enough.
koji already support this. Is this the sub-architecture the proposal
is referring to ? (using koji add-pkg f31 glibc
--extra-arches=EXTRA_ARCHES ... ).
The list of packages having a second optimized build can be as large
as the packages provided by the server spin and any additional
packages that would opt-in.
Personally, I would like to see some "numbers" of the performance with
avx optimized build (using copr repo on few key packages ).
And I expect optimizing some packages would have low impact, so maybe a
Nicolas (kwizart)