Announcement

Collapse
No announcement yet.

OpenSUSE Developers Continue Discussing x86_64 Microarchitecture Feature Levels

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Setif View Post
    I think the main obstacle for distro maintainers to default to x86_64_v3 is that Pentium and Celeron CPUs don't support AVX2 until recently.
    For enterprise targeted distros (where the real money is) one is mostly looking at the server class products where v3 is probably close to being on all the deployed equipment. However, as you point out, consumers (and especially people hanging on to their older systems) may not be running such systems. The performance advantages for v2 and v3 are somewhat compelling for some applications (and even more compelling when you are running large server farms). While HWCAPS can be a solution for some, applications (and/or their build systems) need to be modified to do so, making it problematic for some.

    Red Hat regularly moves the bar forward for their platforms, and EL9 for x86_64 requires v2 (which was apparently based on asking their enterprise customers what those customers had deployed as of a few years ago when the architecture target was decided). I don't think anyone will be surprised when it gets raised to v3 in some future release. Since "out of the box" performance is a common testing criteria, other enterprise distros are going to move forward too, and those enterprise distros are only trying to decide on the when, not the if.

    Comment


    • #22
      Originally posted by CommunityMember View Post
      For enterprise targeted distros (where the real money is) one is mostly looking at the server class products where v3 is probably close to being on all the deployed equipment.
      SuSE used to have a product called SLED (SuSE Linux Enterprise: Desktop). Does that still exist? Is that not a user segment that ALP is meant to address? Do we not think enterprises are running their distro of choice on mini-desktops and things like point-of-sale terminals?

      Originally posted by CommunityMember View Post
      While HWCAPS can be a solution for some, applications (and/or their build systems) need to be modified to do so, making it problematic for some.
      I understand it's not a magic bullet, but the number of packages that would benefit significantly from v3 is also pretty small (probably < 1%?). So, there should be a relatively small amount of work to get most of the benefits.

      Originally posted by CommunityMember View Post
      Red Hat regularly moves the bar forward for their platforms, and EL9 for x86_64 requires v2 (which was apparently based on asking their enterprise customers what those customers had deployed as of a few years ago when the architecture target was decided).
      All that argues is to move to v2.

      Originally posted by CommunityMember View Post
      I don't think anyone will be surprised when it gets raised to v3 in some future release.
      Unless/until they announce definite plans for moving to v3, this point is moot.

      Originally posted by CommunityMember View Post
      other enterprise distros are going to move forward too, and those enterprise distros are only trying to decide on the when, not the if.
      Nobody is arguing to stay on v1 or v2 forever. Just not to go to v3, when lots of new hardware is still being sold that's v2-only. Sheesh. Talk about lack of nuance.
      Last edited by coder; 16 August 2022, 02:18 PM.

      Comment


      • #23
        Originally posted by coder View Post
        You're looking at the wrong thing. Instead of looking at when the first CPU was released that supported v2 features, you need to look at when the last CPUs were released that don't support v3. And those are still shipping in new systems, as of today. Chromebooks, entry-level laptops, low-end NUCs, mini-PCs, and embedded.
        Again, this might not matter. How many Leap users are on these systems? Maybe > 90% of Leap users are on AVX capable systems. Basing hardware decisions for your specific distro on what could possibly be out there resulting in systems that are slower for everyone else isn't good product planning. There will always be Antix and other distros targeting low end hardware.

        Originally posted by coder View Post
        Again, why not simply use glibc's HWCAPS? Nobody seems to answer this. It lets you make progress at a faster rate -- even enabling you to utilize v4 -- without having to leave people behind.
        I'm all for whatever solution moves the ball forward on performance and actually gets implemented by the distros.

        Comment


        • #24
          Originally posted by Setif View Post
          I think the main obstacle for distro maintainers to default to x86_64_v3 is that Pentium and Celeron CPUs don't support AVX2 until recently.
          Can't they maintain two branches, one for AVX2 and one for non-AVX2? That way, people with AVX2 could benefit while others won't be left unsupported. Then, at a future date, they could simply drop the latter.

          Comment


          • #25
            What people seem to be missing is that with hwcaps you can have your cake and eat it too. Sure, not everything will be easy to build that way. But not everything needs it. Most software I use is not performance critical. I don't care if my text editor, email client or terminal emulator is built with a more modern target. Not do I care about the settings application of my DE of choice.

            The way I see it, they should target getting hwcaps up and running for glibc, language runtimes (libstdc++, python, perl etc), and any libraries that are deemed to be performance critical for tasks where performance actually matters.

            That way the overall build times will only increase moderately while still getting a lot of "bang for the buck" as Americans say.

            Media libraries came to mind as a possible category for optimisation, but given that most of those probably already use optimised code paths with inline asm or intrinsics, it probably won't make a difference.

            Compilers (gcc, clang, rustc) might be a good target too, as something that takes a lot of runtime. Though I don't know how much x86-v3 would help there. Benchmarking is needed.
            ‚Äč

            Comment


            • #26
              Originally posted by Vistaus View Post
              Can't they maintain two branches, one for AVX2 and one for non-AVX2? That way, people with AVX2 could benefit while others won't be left unsupported. Then, at a future date, they could simply drop the latter.
              HWCAPS has this ability, but you can choose which among the 4 architecture versions to support, on a package-by-package basis. That way, you don't need to bother with special builds for packages and architecture versions which don't benefit (hint: Phoronix Test Suite can help you determine which ones these are!).

              Comment


              • #27
                Originally posted by Jedibeeftrix View Post

                You're not wrong, but in so far as that statement is relevant to this point:

                "Without hard data showing that a meaningful percentage of your user base will be impacted"

                Will weird and wonderful landfill-chromebooks constitute a meaningful percentage of the opensuse ALP userbase in ~2024?
                No idea about SUSE, but 13% of Steams users do not have v3. 1.1% do not have v2.

                Comment


                • #28
                  Originally posted by carewolf View Post
                  No idea about SUSE, but 13% of Steams users do not have v3. 1.1% do not have v2.
                  And gamers (i.e. the people using Steam) are more likely than average to be running newer & higher-end hardware.

                  Comment


                  • #29
                    Originally posted by Setif View Post
                    I think the main obstacle for distro maintainers to default to x86_64_v3 is that Pentium and Celeron CPUs don't support AVX2 until recently.
                    Intel is still releasing new CPUs as of *last year* that don't support v3, and not just "some" but *"most"* of those systems will still be in use at least 5 years from now, and possibly as many as 10. The argument that "v3 is Haswell and therefore all CPUs still in service have it" isn't just hopelessly wrong in its own right, it's so wrong that it isn't even framing the issue correctly.

                    There just isn't a sane way to handle this other than making a *runtime* decision.

                    The next best option would probably be something along the lines of Ubuntu's HWE approach, with machines opting in to higher feature levels, but nobody's going to burn the resources on producing something like that when only a fraction of their users care about it in the first place.

                    Comment


                    • #30
                      Instead of x32 and x64, how about recent x64 and older x64.

                      Comment

                      Working...
                      X