Announcement

Collapse
No announcement yet.

IBM Scores More POWER Open-Source Performance Optimizations

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

  • IBM Scores More POWER Open-Source Performance Optimizations

    Phoronix: IBM Scores More POWER Open-Source Performance Optimizations

    Following our POWER9 Linux benchmarks earlier this year, IBM POWER engineers have continued exploring various areas for optimization within the interesting open-source workloads tested. Another batch of optimizations are pending for various projects...

    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
    A lot of packages fail to use optimised compiler flags or override any system supplied flags for upstream flags. There is a tendency amongst many projects to feel they own the compiler flags, since (reasonably) any bug reports made with non-standard flags are hard to diagnose. This has recently been extended to producing run-time code selection (optimising for a specific CPU supporting a given ISA extension) even when this results in an invalid psABI mismatch when linking with objects built for the host when the build environment is explicitly targeting a system.

    Gentoo carries quite a few downstream patches "fixing" upstream decisions to ignore user CFLAGS/LDFLAGS etc, and I have a whole lot more for the systems I support. I think there needs to be some co-ordination with how this is approached so that projects can detect compiler support for a given set of vector intrinsics, for example, and enable their use for all supported CPUs independent of architecture with less dependency on inline asm snippets and -march overrides.

    Comment


    • #3
      I believe that is on IBM best interest to loan POWER workstations to the highest number of developers they financially can.

      Linux didn't became the fine tuned software it is now on the AMD64 architecture, without widespread access to the machines.

      So in the long run, is better to convince marketing to finance this now, than have awkward meetings in the future trying to explain why POWER didn't became more successful.

      Comment


      • #4
        Originally posted by M@GOid View Post
        I believe that is on IBM best interest to loan POWER workstations to the highest number of developers they financially can.

        Linux didn't became the fine tuned software it is now on the AMD64 architecture, without widespread access to the machines.

        So in the long run, is better to convince marketing to finance this now, than have awkward meetings in the future trying to explain why POWER didn't became more successful.
        Typically IBM will provide test hardware, but usually to large dev ops organizations that have very large investments in the POWER ISA in application and database support first.

        Comment


        • #5
          Originally posted by M@GOid View Post
          I believe that is on IBM best interest to loan POWER workstations to the highest number of developers they financially can.

          Linux didn't became the fine tuned software it is now on the AMD64 architecture, without widespread access to the machines.

          So in the long run, is better to convince marketing to finance this now, than have awkward meetings in the future trying to explain why POWER didn't became more successful.
          Wouldn't say no... ;-)

          Comment


          • #6
            I would like to buy one of those Talos machines, to use as a main PC, it is capable of whipping Intel/AMD in terms of theoretical performance, however right now due to lack of software tuning, we are not taking full advantage of that performance...

            Comment


            • #7
              Originally posted by s_j_newbury View Post
              A lot of packages fail to use optimised compiler flags or override any system supplied flags for upstream flags. There is a tendency amongst many projects to feel they own the compiler flags, since (reasonably) any bug reports made with non-standard flags are hard to diagnose. This has recently been extended to producing run-time code selection (optimising for a specific CPU supporting a given ISA extension) even when this results in an invalid psABI mismatch when linking with objects built for the host when the build environment is explicitly targeting a system.

              Gentoo carries quite a few downstream patches "fixing" upstream decisions to ignore user CFLAGS/LDFLAGS etc, and I have a whole lot more for the systems I support. I think there needs to be some co-ordination with how this is approached so that projects can detect compiler support for a given set of vector intrinsics, for example, and enable their use for all supported CPUs independent of architecture with less dependency on inline asm snippets and -march overrides.
              I think the Linux userspace would actually benefit immensely from living in one repo, like the development model at Google for Android among others. -fPIE, -fPIC, other security changes, -flto, -O2, -O3, other optimizations, any PGO changes, -Werror=* changes, and any LDFLAG changes, should all be accepted upstream, and be easy to test against any downstream breaks. Gentoo makes this somewhat sane with portage, but distros can only do so much.

              Redhat/Fedora use these gcc flags: https://developers.redhat.com/blog/2...ker-flags-gcc/
              Ubuntu has this page for it's security changes: https://wiki.ubuntu.com/Security/Features
              I'm sure others have similar pages and are sharing patches or are reinventing the wheel.

              Comment


              • #8
                The Raptor systems, are definitely in the TR category in terms of price and performance, though not as many desktop applications will be supported on the former, and you might even seen improved performance for Java workloads on the later. If you have an older TR system, upgrading to more cores makes sense. If you just want a new libre system and try a new arch, the Raptor systems are compelling. Though I'm not saying anything new, I'm glad to see a new alternative be more widely available.

                Comment

                Working...
                X