Fedora 42 Looks To Ship Optimized Executables For Different x86_64 Capabilities

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67416

    Fedora 42 Looks To Ship Optimized Executables For Different x86_64 Capabilities

    Phoronix: Fedora 42 Looks To Ship Optimized Executables For Different x86_64 Capabilities

    Fedora Linux has already supported making use of glibc HWCAPs for allowing libraries to be built for different x86_64 micro-architecture feature levels for performance-sensitive code where it can pay off when leveraging AVX/AVX2 or other newer Intel/AMD CPU instruction set extensions. For Fedora 42 is now a proposal to extend that further to allow binary executables to also leverage glibc HWCAPs for better performance...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • mxan
    Senior Member
    • Jun 2022
    • 291

    #2
    distros really ought to standardise on v3 which would make haswell-era hardware the baseline (i.e. still over 10 years old). anything older is realistically too old for modern use

    Comment

    • sophisticles
      Senior Member
      • Dec 2015
      • 2621

      #3
      Sounds to me like more busy work so that Fedora can keep telling themselves that they matter.

      Comment

      • edxposed
        Senior Member
        • Jan 2023
        • 317

        #4
        Things like FFmpeg that still force building MMX and SSE2 inline ASM in 2025 probably won't get much improvement from x86-64-v3, and it's impossible to get rid of MMX shit unless you're willing to give up all assembly optimizations. gcc/clang could have automatically promoted SSE instructions to AVX equivalents for x86-64-v3, but FFmpeg just pathologically rejected intrinsics and even GAS and stuck with outdated NASM.

        Comment

        • ezst036
          Senior Member
          • Feb 2018
          • 683

          #5
          Originally posted by mxan View Post
          anything older is realistically too old for modern use
          Only someone who's never used a Core 2 quad or even Core 2 duo on a modern distro could say this.

          Comment

          • decadarkness
            Junior Member
            • Jul 2022
            • 11

            #6
            Originally posted by edxposed View Post
            but FFmpeg just pathologically rejected intrinsics and even GAS and stuck with outdated NASM.
            Asm is used only when intrinsics are not enough. FFmpeg could dynamically dispatch hot functions instead. And I guess they do, just dont have resources to rewrite everything.

            Why GAS is modern and NASM is outdated?

            Comment

            • pokeballs
              Junior Member
              • Sep 2024
              • 38

              #7
              I was wondering why there was no mechanism in place for executables, I hope this gets popular on more distro

              Comment

              • edxposed
                Senior Member
                • Jan 2023
                • 317

                #8
                Originally posted by decadarkness View Post
                Asm is used only when intrinsics are not enough. FFmpeg could dynamically dispatch hot functions instead. And I guess they do, just dont have resources to rewrite everything.

                Why GAS is modern and NASM is outdated?
                FFmpeg does allow aarch64/riscv limited use of some intrinsics, but x86 only NASM or inline ASM is allowed. Their video codecs have very good and comprehensive x86 ASM, but many audio codecs don't and only have ancient inline MMX/SSE2, which are not only unoptimizable on their own, but also affect the optimization of nearby C code.

                NASM is not actively developed today.

                NASM is extremely slow, if you build x86 FFmpeg with ccache, you will find that 99% of the build time is wasted in NASM. AArch64 builds are very fast.

                NASM does not support SSE2AVX, if you build GAS assembly with -Wa,-msse2avx, gcc/clang will automatically convert SSE to AVX to avoid SSE-AVX transition penalty, and NASM does not support this.

                Comment

                • sobrus
                  Senior Member
                  • Apr 2021
                  • 191

                  #9
                  Originally posted by mxan View Post
                  distros really ought to standardise on v3 which would make haswell-era hardware the baseline (i.e. still over 10 years old). anything older is realistically too old for modern use
                  I'm pretty happy with my Ivy Bridge Thinkpad X230 with 16GB RAM and two internal 2TB SSDs. It won't do compute heavy things (got 5950x/128GB for that) but for normal usage it's still enough. Currently it's running ALHP v2.

                  Also, there are some not-so-old Comet Lake Intel CPUs that don't support AVX or AVX2, for example
                  Last edited by sobrus; 11 January 2025, 03:51 PM.

                  Comment

                  • OneTimeShot
                    Senior Member
                    • Apr 2010
                    • 721

                    #10
                    It always surprised me that ELF was never extended to allow multiple architectures (or variants of architectures) in a single file.

                    Comment

                    Working...
                    X