[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
From:       Jason L Tibbitts III <tibbs () math ! uh ! edu>
Date:       2019-07-24 16:51:02
Message-ID: ufaftmv1imh.fsf () epithumia ! math ! uh ! edu
[Download RAW message or body]

>>>>> "FW" == Florian Weimer <fweimer@redhat.com> writes:

FW> ELF multilib DSOs inside RPMs result in code deduplication,
FW> affecting container image size.

I think it's important to quantify this kind of thing.  I think we can
all agree that there is very little benefit to duplicating every single
library, so extra space usage would come only from libraries which meet
all of:

* Compiling with AVX2 (or whatever) provides benefit
* Special runtime detection code isn't included
* Function multiversioning or the fancy target_clones attribute isn't
  used

And by implementing the latter two, the set can shrink.

So, really, how much space are we really talking about here?

FW> Currently, there is no dynamic loader
FW> support for selecting an AVX2 baseline.  Fixing this requires
FW> complete agreement among all involved parties what the actual CPU
FW> requirements are (currently, not even glibc and GCC agree what
FW> "haswell" means, the closest we have to an AVX2 baseline).  But
FW> similar fixes are required for any baseline update.

I have a hard time believing that solving that would be somehow less
preferable than either making Fedora unusable on a whole class of
hardware or splitting off a completely new architecture.

 - J<
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org

[prev in list] [next in list] [prev in thread] [next in thread]