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 ? > * 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) _______________________________________________ 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
