Announcement

Collapse
No announcement yet.

openSUSE Tumbleweed Sets Great Example With x86-64-v3 HWCAPS

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

  • openSUSE Tumbleweed Sets Great Example With x86-64-v3 HWCAPS

    Phoronix: openSUSE Tumbleweed Sets Great Example With x86-64-v3 HWCAPS

    The rolling-release openSUSE Tumbleweed recently began rolling out optional x86-64-v3 optimized packages for those on roughly Intel Haswell or newer systems and wanting to squeeze out maximum performance from their hardware. The selection of x86-64-v3 packages built by openSUSE Tumbleweed is currently rather limited, but hopefully this major Linux distribution joining the HWCAPS party will lead other Linux distributions to follow suit...

    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

  • #2
    Why not building *all* packages with v3 optimizations? If the build system is automated it shouldn't necessary to spend time deciding which packages are worthwhile for optimizing.
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

    Comment


    • #3
      Originally posted by darkbasic View Post
      Why not building *all* packages with v3 optimizations? If the build system is automated it shouldn't necessary to spend time deciding which packages are worthwhile for optimizing.
      CachyOS already did that.
      CachyOS re-build full Arch Linux repo with x86-64v3 and x86-64v-4 is also planned.

      🚀 CachyOS is an Arch Linux-based distribution that offers an easy installation, several customization options to suit every user, and special optimizations for improved performance while remaining simple.

      Archlinux Kernel based on different schedulers and some other performance improvements. - GitHub - CachyOS/linux-cachyos: Archlinux Kernel based on different schedulers and some other performance i...


      Comment


      • #4
        Originally posted by darkbasic View Post
        Why not building *all* packages with v3 optimizations? If the build system is automated it shouldn't necessary to spend time deciding which packages are worthwhile for optimizing.
        Probably similar reasons as ALHP.GO:
        Here are some that are going to stay with specific reasons: * tensorflow, pytorch: takes ages to build and mountains of disk space that I simple do not have to spare on the buildserver * tensorflow-cuda: see tensorflow * gcc: Would blow up your local build process for e.g. AUR packages * electron*: Each version takes a _lot_ of buildtime, and there are 8 versions of electron in the repo (for each march!) at the time of writing this. Current list: - tensorflow - tensorflow-cuda - python-pytorch - python-pytorch-cuda - python-pytorch-opt - python-pytorch-opt-cuda - electron* - gcc - dhclient (#20) - [ctags](https://git.harting.dev/anonfunc/ALHP.GO/issues/16#issuecomment-208) - bluez (#31) - bandwhich (#45) - mold (https://git.harting.dev/ALHP/ALHP.GO/issues/136#issuecomment-1872) - julia (https://git.harting.dev/ALHP/ALHP.GO/issues/16#issuecomment-1935) [Packages build without LTO](https://github.com/InBetweenNames/gentooLTO/blob/435a9d968854fef21015796a5f464243dc4caa03/sys-config/ltoize/files/package.cflags/lto.conf)

        Buildserver resources are limited.

        Comment


        • #5
          Originally posted by Lycanthropist View Post

          Probably similar reasons as ALHP.GO:
          Here are some that are going to stay with specific reasons: * tensorflow, pytorch: takes ages to build and mountains of disk space that I simple do not have to spare on the buildserver * tensorflow-cuda: see tensorflow * gcc: Would blow up your local build process for e.g. AUR packages * electron*: Each version takes a _lot_ of buildtime, and there are 8 versions of electron in the repo (for each march!) at the time of writing this. Current list: - tensorflow - tensorflow-cuda - python-pytorch - python-pytorch-cuda - python-pytorch-opt - python-pytorch-opt-cuda - electron* - gcc - dhclient (#20) - [ctags](https://git.harting.dev/anonfunc/ALHP.GO/issues/16#issuecomment-208) - bluez (#31) - bandwhich (#45) - mold (https://git.harting.dev/ALHP/ALHP.GO/issues/136#issuecomment-1872) - julia (https://git.harting.dev/ALHP/ALHP.GO/issues/16#issuecomment-1935) [Packages build without LTO](https://github.com/InBetweenNames/gentooLTO/blob/435a9d968854fef21015796a5f464243dc4caa03/sys-config/ltoize/files/package.cflags/lto.conf)

          Buildserver resources are limited.
          Perhaps they could utilize the OBS

          The openSUSE Build Service is the public instance of the Open Build Service (OBS) used for development of the openSUSE distribution and to offer packages from same source for Fedora, Debian, Ubuntu, SUSE Linux Enterprise and other distributions..​
          If SUSE/openSUSE have build server resource issues we have much greater problems

          Comment


          • #6
            Originally posted by Lycanthropist View Post

            Probably similar reasons as ALHP.GO:
            Here are some that are going to stay with specific reasons: * tensorflow, pytorch: takes ages to build and mountains of disk space that I simple do not have to spare on the buildserver * tensorflow-cuda: see tensorflow * gcc: Would blow up your local build process for e.g. AUR packages * electron*: Each version takes a _lot_ of buildtime, and there are 8 versions of electron in the repo (for each march!) at the time of writing this. Current list: - tensorflow - tensorflow-cuda - python-pytorch - python-pytorch-cuda - python-pytorch-opt - python-pytorch-opt-cuda - electron* - gcc - dhclient (#20) - [ctags](https://git.harting.dev/anonfunc/ALHP.GO/issues/16#issuecomment-208) - bluez (#31) - bandwhich (#45) - mold (https://git.harting.dev/ALHP/ALHP.GO/issues/136#issuecomment-1872) - julia (https://git.harting.dev/ALHP/ALHP.GO/issues/16#issuecomment-1935) [Packages build without LTO](https://github.com/InBetweenNames/gentooLTO/blob/435a9d968854fef21015796a5f464243dc4caa03/sys-config/ltoize/files/package.cflags/lto.conf)

            Buildserver resources are limited.
            ALHP builds most Arch packages. The few examples they list (electron/ml frameworks) are just particularly obnoxious to build, and already have v3 packages in the Arch repo.

            But ALHP doesn't use HWCAPs. Maybe that requires manual changes, which is why its more difficult to implement globally?
            Last edited by brucethemoose; 06 March 2023, 12:51 PM.

            Comment


            • #7
              Originally posted by brucethemoose View Post

              ALHP builds most Arch packages. The few examples they list (electron/ml frameworks) are just particularly obnoxious to build, and already have v3 packages in the Arch repo.

              But ALHP doesn't use HWCAPs. Maybe that requires manual changes, which is why its more difficult to implement globally?
              Yeah, but you were suggesting that perhaps openSUSE was lacking in build resources like a small project like ALHP. I was referring to openSUSE and the SUSE organization in general. They operate massive public-facing build clusters so them lacking build server resources shouldn't be a reason to not do their entire package-set in v3.

              Sorry if you thought I was talking about ALHP.

              Comment


              • #8
                Originally posted by skeevy420 View Post

                Yeah, but you were suggesting that perhaps openSUSE was lacking in build resources like a small project like ALHP. I was referring to openSUSE and the SUSE organization in general. They operate massive public-facing build clusters so them lacking build server resources shouldn't be a reason to not do their entire package-set in v3.

                Sorry if you thought I was talking about ALHP.
                I dont think they are buildserver limited either, but I was wondering if they are maintainer limited.

                ALHP adds build flags to PKGBUILDs and simply skip builds that fail, so the v3 system is mostly automated. CachyOS is similar. But if HWCAPs requires manual changes to packages, thats a lot of (human) work and maybe too much of a maintinence burden for OpenSUSE.
                Last edited by brucethemoose; 06 March 2023, 01:27 PM.

                Comment


                • #9
                  Originally posted by darkbasic View Post
                  Why not building *all* packages with v3 optimizations? If the build system is automated it shouldn't necessary to spend time deciding which packages are worthwhile for optimizing.
                  Because OpenSUSE is TESTED rolling release. They won't release packages unless they are tested.

                  Comment


                  • #10
                    Kudos to OpenSUSE for offering these packages. Hope Debian and Ubuntu will follow suit.

                    Comment

                    Working...
                    X