On Fri, Jun 21, 2024 at 12:27:25PM -0400, Stephen Smoogen wrote:
> On Fri, 21 Jun 2024 at 07:27, Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
> > So what is the reason to not treat x86_64_v2 as different arch then
> > x86_64_v{1,3}. Why we keep having this discussion instead of fire one
> > more build? Users would need to choose v1 / v2 / v3 ISO but what else?
>
> I can think of three problems which would need to be dealt with
>
> 1. Resource limitations in infrastructure hardware. You are going to
> add to the amount of builds on 1 set of hardware which is already
> doing x86_64 and i686. You are going to add to the storage issues that
> Fedora Infrastructure has to juggle on the maximum 100TB koji
> partition (with 90TB causing some amount of degradation) due to extra
> packages and composes.
> 2. Resource limitations in infrastructure staff. Fedora Infra is doing
> more with less and each additional architecture and focus increases
> that load.
> 3. Resource limitations on packagers. Packagers will need to add yet
> another bug set to cover and determine "is it only on VX" or not.
Another reason: is it actually useful at all?
Benchmarking so far hasn't been mention in this thread. But it was
discussed fairly extensively in previous interations on fedora-devel,
and the results were … not impressive.
The first consideration is that many packages already employ multiple
versions of functions and select the optimal version _at runtime_. In
that case, there is no "baseline architecture", the program works on
all µarchitectures, just faster or slower. This includes various BLAS
libraries, but also very importantly glibc itself with IFUNCS, some
compression libraries, etc. This means that for many programs the
heavy number crunching is already optimized, and raising the
µarchitecture level will have negligible effect on performance.
The second consideration is that many packages are not CPU-bound at
all, or don't perform the kind of processing where AVX and other
instructions make a difference.
So overall, there _might_ be some programs which would benefit from
higher µarchitecture requirements. Before starting a huge effort to
recompile the distro, it'd be prudent to do some local compilations
and benchmarking.
But OK, let's jump forward and we identified a subset of Fedora that'd
benefit. For those programs, a runtime approach based on IFUNCS or
equivalent is the most powerful. Only the hot paths need to be
targeted, delivering the same benefits as raising the baseline for the
whole program, while being transparent to the user. Also, this
approach can be more flexible, because it's OK to have many different
variants, rather than just targeting four µarchitecture levels. It
also requires much less resources, because we don't deliver multiple
versions of the package, but instead a few versions of the hot
functions, all in the same binary.
Only for programs where there is potential benefit, but we cannot do
IFUNCS, compiling with a higher baseline is a useful approach.
Overall, I think that we _should_ have more software optimized
for newer CPUs, but the solutions should be targeted at the right
packages and the right parts of the code. Just compiling everything
multiple times is IMO a waste of resources.
Zbyszek
--
_______________________________________________
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
