On Tue, Jul 23, 2019 at 10:44 AM Nicolas Chauvet <kwizart@xxxxxxxxx> wrote: > > Le mar. 23 juil. 2019 à 08:30, Igor Gnatenko > <ignatenkobrain@xxxxxxxxxxxxxxxxx> a écrit : > > > > 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") > x86_64avx2 ? or even avx2 ? I just did not want to bikeshed :) > > * 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. I would leave this decision to Florian. Strictly speaking, we are talking not only about avx2, but some other instructions / options which might affect system as a whole (like FMA). So whether it is used by all packages or by few selected ones require a bit more investigation. > 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 Yes, number would be really useful. > > Nicolas (kwizart) > _______________________________________________ > 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 _______________________________________________ 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
