Le mar. 23 juil. 2019 à 09:38, Nicolas Chauvet <kwizart(a)gmail.com> a écrit :
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
> > > 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:email@example.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
> > > 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_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
benchmark need to be done in order to enable an alternate build on
a selected set of packages.
(previous email sent too early).