On 6/19/22 16:36, Gordon Messmer wrote: > On 6/17/22 12:15, Demi Marie Obenour wrote: >> On 6/17/22 01:41, Tomasz Torcz wrote: >>> I can only concur. Say what you want about Phoronix benchmark, but >>> they consistently benchmark different distributions And Fedora >>> consistently is lagging behind. Latest article is at >>> https://www.phoronix.com/scan.php?page=article&item=h1-2022-linux >>> >>> Slowing Fedora even further is really undesirable. >> What would it take to make Fedora faster? > > > If you go back a few years, it was pretty common for Fedora to perform > below average in these benchmarks, and that really isn't the case any > more. The top performing systems in these benchmarks are Clear Linux > and RHEL rebuilds (which, in this context, I think we can probably just > treat as a proxy for RHEL performance.) Clear and RHEL (rebuilds) > probably get most of their advantages from building for an x86_64-v2 > microarchitecture, which Fedora discussed and rejected last year (after > discussing and rejecting a proposal to build for x86_64-v3 two years > before that.) If you exclude Clear and RHEL (rebuilds), Fedora's > showing in the Phoronix benchmarks above is, subjectively, pretty good. > So, I don't think that Tomasz's claim that Fedora is consistently > lagging behind is true for the last couple of years, though it had been > in the past. (It is also probably true that when Fedora Workstation is > tested instead of Fedora Server, btrfs impacts some benchmarks.) > > To Demi's question, though, I would venture a guess that building glibc > (and possibly some other libraries) for more modern microarchitectures > and shipping that support in hwcaps would probably be a big step > forward, at the cost of some disk space. It was mentioned in Neal's > x86_64-v2 thread, but that discussion didn't seem to go anywhere. > Building the whole OS for a more modern microarchitecture would probably > also help, at the cost of compatibility with older hardware, and that > doesn't seem like an trade-off Fedora is willing to consider today. Are there any cases where there is no trade-off? For instance, anything that requires KVM or Xen (except Xen PV) requires hardware virtualization support in the CPU, so it can be built under the assumption that such support is present. Therefore, it only needs to support CPUs that are new enough to have such support. Another option would be to exclude CPUs that are no longer receiving microcode updates for security vulnerabilities; this is especially true for virtualization packages. -- Sincerely, Demi Marie Obenour (she/her/hers)
Attachment:
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
