Announcement

Collapse
No announcement yet.

GCC vs. LLVM Clang vs. AOCC Compiler Benchmarks On The AMD EPYC 7742

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

  • GCC vs. LLVM Clang vs. AOCC Compiler Benchmarks On The AMD EPYC 7742

    Phoronix: GCC vs. LLVM Clang vs. AOCC Compiler Benchmarks On The AMD EPYC 7742

    While AMD's hardware folks were launching the EPYC 7002 series, their software crew was pushing out the AMD Optimizing C/C++ Compiler 2.0 with support/optimizations for the Zen 2 micro-architecture. Using the top-end AMD EPYC 7742 in a 2P Linux server configuration, here are C/C++ compiler benchmarks looking at the performance when built by the GNU Compiler Collection (GCC), LLVM Clang, and AOCC 2.0.

    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
    nice, LLVM Clang 9.0 SVN looking great … now all I need is a ryzen 9 3950x for my mini-itx workstation: https://www.youtube.com/watch?v=jZNvj67PAEc
    Last edited by rene; 09 August 2019, 07:06 AM.

    Comment


    • #3
      This is really showing AMD are wasting their and every body else's time with an optimized proprietary fork rather than contributing upstream. In the time they've got their code out of the door it's already been superseded on a performance standing by the generic upstream optimizations. If they'd worked with upstream their optimizations would given them an actual performance edge for "-march" targeted code. Even better if they'd worked with upstream GCC too.

      Comment


      • #4
        Originally posted by s_j_newbury View Post
        This is really showing AMD are wasting their and every body else's time with an optimized proprietary fork rather than contributing upstream. In the time they've got their code out of the door it's already been superseded on a performance standing by the generic upstream optimizations. If they'd worked with upstream their optimizations would given them an actual performance edge for "-march" targeted code. Even better if they'd worked with upstream GCC too.
        I don't disagree that their own optimized fork is hardly yielding worthwhile results, but, unless they're making optimizations that apply to all architectures (which is highly unlikely at this point), I don't see the need for them to submit something upstream. The reason why you get architecture-specific optimizations is because they're supposed to take advantage of that hardware's strengths. So, what works well for AMD could be bad for anyone (or everyone) else. That doesn't so much work in AMD's favor when they don't command the majority of the market.

        Comment


        • #5
          Originally posted by schmidtbag View Post
          I don't disagree that their own optimized fork is hardly yielding worthwhile results, but, unless they're making optimizations that apply to all architectures (which is highly unlikely at this point), I don't see the need for them to submit something upstream. The reason why you get architecture-specific optimizations is because they're supposed to take advantage of that hardware's strengths. So, what works well for AMD could be bad for anyone (or everyone) else. That doesn't so much work in AMD's favor when they don't command the majority of the market.
          That's an argument in favour of -march=, not an argument in favour of a proprietary fork. They're forgoing "optimizations that apply to all architectures" by committing themselves to maintaining their fork which can only ever be playing catch-up. Surely if they want something that works in their favour, given they don't command that majority, it's to maximise their competitive advantage. That includes the ability of their customers to compile optimal code taking advantage of the hardware strengths especially at the expense of the competition!

          By the way I don't have any skin in the game since I'm not going to buy a new CPU with ME/PSP, which is a shame since I've bought many AMD CPUs over the years starting with a AMD 5x86 (aka X5-133) way back when. Fortunately, my highly optimized Gentoo on my undervolted FX-9370 is fast enough for now... :-)

          Comment


          • #6
            dav1d results in FPS

            4K
            LLVM Clang 9.0 SVN 311.68
            GCC 9.1.0 312.76
            GCC 10.0 Git 322.85
            AOCC 2.0 323.43
            1080p
            LLVM Clang 9.0 SVN 741.36
            GCC 10.0 Git 755.35
            AOCC 2.0 755.35
            GCC 9.1.0 758.53

            Comment


            • #7
              As I understand it, LLVM is basically Apple and GCC is freedom. And Apple still can't really beat freedom so yeah!

              Comment


              • #8
                Originally posted by eltomito View Post
                As I understand it, LLVM is basically Apple and GCC is freedom. And Apple still can't really beat freedom so yeah!
                Your understanding is dumb.

                Comment


                • #9
                  Originally posted by eltomito View Post
                  As I understand it, LLVM is basically Apple and GCC is freedom. And Apple still can't really beat freedom so yeah!
                  GCC actually has a more burdensome and restrictive license than LLVM... not having a license that requires contribution back doesn't seem to be slowing down LLVM either if anything it promotes more commercial contributions.

                  Comment


                  • #10
                    Originally posted by cb88 View Post

                    GCC actually has a more burdensome and restrictive license than LLVM... not having a license that requires contribution back doesn't seem to be slowing down LLVM either if anything it promotes more commercial contributions.
                    You know what this article is about, right? That's exactly what's happened, AMD has kept architecture specific optimization contributions to itself for *some* <<commercial reason>> . Whether you think it's a generally good thing or not, in this specific case it has shown that the customer/user loses out since they don't get access to a compiler that has both the latest general optimization improvements AND architecture specific optimization improvements.

                    This is different than ICC for Intel, since Intel has a commercial interest in pushing ICC to developers so that resultant commercial binary distributions are both optimal for their platform and disadvantage their competitors. AMD lacks a mature proprietary compiler infrastructure like Intel, but maybe AMD desired to follow this same <<commercial reason>>, it would be unfortunate, and be impossible if they couldn't just fork llvm/clang but had to write a compiler from scratch.

                    Comment

                    Working...
                    X