On Tue, Jul 23, 2019 at 12:08 PM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote:
>
> Igor Gnatenko wrote:
> > 1. Lower requirement to something like SSE4 and select other CPU
> > features which are available in most of CPUs for last decade.
>
> Sorry, but -1 to SSE4 too. One of my machines supports only up to SSSE3, and
> other replies in this thread have also suggested SSSE3 as the most we can
> assume. And if you ask me, we should just stick to SSE2 as the baseline.
> What are the big gains to be had from SSE3, SSSE3, SSE4.1, and SSE4.2?
> Especially if you limit it to packages that don't do runtime detection?
> (Performance-sensitive software SHOULD do runtime detection, and most of it
> does, e.g., OpenBLAS.)
I used SSE4 as an example. Obviously one needs to spend time digging
into all this and find appropriate set.
>From what I saw, openblas does not do any runtime detection. You
either compile it with avx2 or not. And in runtime it will check
whether it was enabled during compilation and use some kind of
fallback.
> > 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.
>
> That would at least be tolerable, but still, I'm against it. It sounds like
> a huge waste of resources for very little practical gain to me.
Nicolas pointed out that it is possible to add extra arches on package
basis. So if we choose to just build some packages with these settings
enabled, we can do that. But if from the change would benefit most of
the packages, building all of them sounds reasonable.
And after all, it is Fedora resources, so you probably don't have to
care much about it. It is also not some uncommon architecture where 1
server costs billions. So I think if benefit is big, we could find
resources for doing this.
>
> > 3. Invent some mechanism for selecting appropriate feature set in
> > runtime (somebody mentioned fat binaries in this thread).
>
> We already have 2 such mechanisms:
> * several upstream software packages check CPUID directly. See, e.g., how
> OpenBLAS does it. Or the performance-sensitive parts of Chromium. Etc.
You can't do several things with this, like FMA.
> * you can drop optimized builds of entire shared objects (.so) into an
> appropriate subdirectory of %{_libdir}. Some profiles such as haswell are
> already supported. If we need more, they can be added.
You are talking about libraries while I am talking about binaries.
> So I don't see a need for fat binaries.
>
> Kevin Kofler
> _______________________________________________
> 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
