Announcement

Collapse
No announcement yet.

Video: 100+ Daily Performance Tests For Clear Linux + Intel's Other Full-Stack Optimizations

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

  • Video: 100+ Daily Performance Tests For Clear Linux + Intel's Other Full-Stack Optimizations

    Phoronix: Video: 100+ Daily Performance Tests For Clear Linux + Intel's Other Full-Stack Optimizations

    A month ago at the Open-Source Summit Europe 2019 in Lyon, France, Intel's Kelly Hammond who serves as the company's Senior Director of System Platform Software talked up their open-source contributions with a particular emphasis on performance. The video from that keynote was recently published for those curious about Intel's open-source work in the name of performance, including Clear Linux...

    http://www.phoronix.com/scan.php?pag...d-2019-Keynote

  • #2
    LOL Intel talking about "performance" of all things after all this security vulnerabilities and mitigations, ..! :-/

    Comment


    • #3
      From the video: 'Better, faster, stronger'. At least they didn't dare to mention 'more secure'.

      Comment


      • #4
        Maybe the time has come where CPU-architecture specific distributions could actually be brought forward as a next step in performance optimizations. The key challenge here is the regression testing and fixing the fallout. It certainly would be a good use for the new high core count CPUs.

        Comment


        • #5
          Originally posted by ms178 View Post
          Maybe the time has come where CPU-architecture specific distributions could actually be brought forward as a next step in performance optimizations. The key challenge here is the regression testing and fixing the fallout. It certainly would be a good use for the new high core count CPUs.
          Better would be a distribution with all cpu optimizations included and choosing the right one for your cpu like clear linux is doing:
          https://clearlinux.org/news-blogs/tr...l-architecture
          The Feature should also work for AMD CPUs.

          Comment


          • #6
            Originally posted by dispat0r View Post

            Better would be a distribution with all cpu optimizations included and choosing the right one for your cpu like clear linux is doing:
            https://clearlinux.org/news-blogs/tr...l-architecture
            The Feature should also work for AMD CPUs.
            In theory. The irony here is that neither ClearLinux nor Glibc upstream enable the fast path for newer AMD processors, https://sourceware.org/bugzilla/show...gi?id=24979#c1
            Hence in practice they "cripple" this functionality for AMD CPU's (like they do with MKL-DNN or other Intel libraries which check for the Genuine Intel string instead of the capabilities of the given CPU - hence they fail to use any advanced vectorization units on AMD, see the recent Matlab workaround). Glibc developers say they need more involvement of AMD because there could be regressions on their CPU's enabling it (see https://sourceware.org/ml/libc-alpha.../msg00155.html). In my opinion the upstream maintainers should enforce that their project runs equally good on either x86 CPU brand and enforce proper testing on both before accepting such code.

            Also, as different CPU architectures have different characteristics there could be additional benefits to be had - not just making use of specific vector instructions but also different scheduling or other architecture-specific decisions.

            Comment


            • #7
              Originally posted by ms178 View Post

              In theory. The irony here is that neither ClearLinux nor Glibc upstream enable the fast path for newer AMD processors, https://sourceware.org/bugzilla/show...gi?id=24979#c1
              Hence in practice they "cripple" this functionality for AMD CPU's (like they do with MKL-DNN or other Intel libraries which check for the Genuine Intel string instead of the capabilities of the given CPU - hence they fail to use any advanced vectorization units on AMD, see the recent Matlab workaround). Glibc developers say they need more involvement of AMD because there could be regressions on their CPU's enabling it (see https://sourceware.org/ml/libc-alpha.../msg00155.html). In my opinion the upstream maintainers should enforce that their project runs equally good on either x86 CPU brand and enforce proper testing on both before accepting such code.

              Also, as different CPU architectures have different characteristics there could be additional benefits to be had - not just making use of specific vector instructions but also different scheduling or other architecture-specific decisions.
              Wow thats bad. Not good that AMD doesn't have someone on it to help the Red Hat guys.

              Comment


              • #8
                What a p.o.s keynote speech. Talking about blowing sunshine up your own ass.

                Comment


                • #9
                  Intel has already been found to be doing sketchy things with their Math libraries (at least on Windows). This includes not using AVX-2 if an AMD CPU is detected among other things. I don't know if I'd trust anything Intel is doing at this point.

                  Comment


                  • #10
                    Originally posted by ms178 View Post

                    In theory. The irony here is that neither ClearLinux nor Glibc upstream enable the fast path for newer AMD processors, https://sourceware.org/bugzilla/show...gi?id=24979#c1
                    Hence in practice they "cripple" this functionality for AMD CPU's (like they do with MKL-DNN or other Intel libraries which check for the Genuine Intel string instead of the capabilities of the given CPU - hence they fail to use any advanced vectorization units on AMD, see the recent Matlab workaround). Glibc developers say they need more involvement of AMD because there could be regressions on their CPU's enabling it (see https://sourceware.org/ml/libc-alpha.../msg00155.html). In my opinion the upstream maintainers should enforce that their project runs equally good on either x86 CPU brand and enforce proper testing on both before accepting such code.

                    Also, as different CPU architectures have different characteristics there could be additional benefits to be had - not just making use of specific vector instructions but also different scheduling or other architecture-specific decisions.
                    That strategy was exactly how Google won the Internet Marketplace in the browsers side..
                    They started developing incompatibilities for others,
                    At the point were the number of regressions( for others players at the time... Microsoft Internet explorer, Opera Browser, the leader in speed at the time.. )were so big, that Others products become crippled and so Google product Chrome Browser become very widely used..

                    Nothing new,
                    That strategy is used a lot in a lot of places.. cripple the others, so that you are "winning"( but in fact is not winning is cheating.. )

                    Comment

                    Working...
                    X