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

  • #11
    Originally posted by s_j_newbury View Post

    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.
    Except you are obviously wrong... AOCC exists so customers that are paying for support form AMD can get direct fastracked fixes that's it... if you aren't in that group you should be running LLVM, all the changes from AOCC eventually make it there if it makes sense for them to anyway...

    Comment


    • #12
      When I write C code, I use the tcc compiler

      It compiles super fast and I love it

      Comment


      • #13
        I hope AMD will create something equivalent to:
        1. Intel MKL (Maybe by supporting OpenBLAS project as a starting point).
        2. Intel SVML (Maybe by supporting SLEEF project as a starting point).

        Having those with well optimized versions for AMD CPU’s will make their CPU’s loved by developers and users.

        Comment


        • #14
          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.
          Uh, AMD contribute plenty to LLVM upstream FFS. Read the LLVM mailing lists, or look at the bug tracker.
          The point of having their own branded compiler is to jam in changes that THEY have control over, for purposes of testing, or keeping things secret till release, or whatever. But anything important gets moved back to trunk as soon as feasible.

          Same as Apple, though obviously Apple's divergence from trunk at any given time can be massive, and some secret sauce (in particular the machine models for everything post-A7) has not (yet? will never?) been released.

          Do you have any evidence of AMD "keeping architecture specific optimization contributions to itself" BEYOND the reasonable duration of "up to a release, then some time to get the patches through the standard LLVM community process and testing"?

          Comment


          • #15
            Originally posted by name99 View Post

            Do you have any evidence of AMD "keeping architecture specific optimization contributions to itself" BEYOND the reasonable duration of "up to a release, then some time to get the patches through the standard LLVM community process and testing"?
            Well, there is the lack of architectural changes with the enablement of znver2 at release; I don't just mean in released versions, but upstream LLVM/GCC were/are not optimized for znver2 yet. The flag was there, but that's about all.

            Look, I'm as much an AMD/ATI fan as anybody, I've been buying AMD CPUs since the '90s and my first ATI graphics card was a VLB Mach64, I don't have a specific problem with AMD, and really appreciate their Open Source policy! That doesn't mean I can't criticize where I see they could do better? I don't think there is any (Intel-style) nefarious plan involved here, and maybe as suggested some of the changes wouldn't be accepted upstream for whatever reason, but right now I suspect znver2 could be better optimized for from both GCC, and LLVM. I can only speculate why that hasn't happened, but it looks to me they didn't want to provide that code until after the release of the new AOCC in order to cast it in a better light.

            Comment


            • #16
              Originally posted by s_j_newbury View Post

              Well, there is the lack of architectural changes with the enablement of znver2 at release; I don't just mean in released versions, but upstream LLVM/GCC were/are not optimized for znver2 yet. The flag was there, but that's about all.

              Look, I'm as much an AMD/ATI fan as anybody, I've been buying AMD CPUs since the '90s and my first ATI graphics card was a VLB Mach64, I don't have a specific problem with AMD, and really appreciate their Open Source policy! That doesn't mean I can't criticize where I see they could do better? I don't think there is any (Intel-style) nefarious plan involved here, and maybe as suggested some of the changes wouldn't be accepted upstream for whatever reason, but right now I suspect znver2 could be better optimized for from both GCC, and LLVM. I can only speculate why that hasn't happened, but it looks to me they didn't want to provide that code until after the release of the new AOCC in order to cast it in a better light.
              I don't follow AMD closely but looking at the LLVM bug reviewer tracker:
              https://reviews.llvm.org/search/query/eiTMfFJRDZ.l/#R
              to me this looks like what I'd expect. The part that's NOT "secret company info", ie the existence of Zen2, is checked in fairly early.
              But the part that gives away important CPU details gets checked in AFTER the big announcement, yesterday in fact (Aug 12).

              Now you can be upset that this wasn't checked in the moment Lisa Su got on the stage. But realistically, that's not the way these things work. Even Apple, that most polished of tech machines, has gaps between when things are announced (at WWDC, or in September) and when they ship (whether as APIs, as OS updates, or as checkins to LLVM).

              Comment

              Working...
              X