Announcement

Collapse
No announcement yet.

AMD AOCC 5.0 Compiler Released With Zen 5 Support, New Optimizations

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

  • AMD AOCC 5.0 Compiler Released With Zen 5 Support, New Optimizations

    Phoronix: AMD AOCC 5.0 Compiler Released With Zen 5 Support, New Optimizations

    With 5th Gen AMD EPYC "Turin" processors now launched, AMD provided a same-day release of their updated AMD Optimizing C/C++ Compiler "AOCC". This is AMD's downstream version of LLVM/Clang/Flang where they provide optimized AMD processor support with code that hasn't yet worked its way up into LLVM proper...

    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
    AMD AOCC is proprietary software, I think AMD should make it open source.

    Comment


    • #3
      Originally posted by uid313 View Post
      AMD AOCC is proprietary software, I think AMD should make it open source.
      With a less permissive license, it would be open-source and everybody could benefit from generic optimizations like:
      - Improved SLP and loop vectorization
      - Improved LICM and loop optimizations
      - Enhanced control/data flow optimizations​
      But here we see the effects of LLVM's "take all, give nothing" license: AMD consumes the work done by countless individuals and other companies, adds their 1% of value - and does not give it back. A good example why the GPL does have to be as restrictive as it is. Otherwise you always have those .... who behave like this.

      Comment


      • #4
        Originally posted by Linuxhippy View Post

        With a less permissive license, it would be open-source and everybody could benefit from generic optimizations like:
        Perhaps. But don't you mean more permissive license there? I interpret "less permissive" to mean "more restricted and limited" like how AOCC is or how the GPL can be considered to be; the forced open "restriction". We can't even add AOCC to repo packages for ease-of-use and installation for end-users and developers alike. No one wants to add someone else's install steps to their install steps -- Step 4: Download, install, and configure the C compiler manually per AMD's instructions. AMD is foolish for making their stuff difficult to use. Ain't nobody wanna use difficult to use stuff.

        But here we see the effects of LLVM's "take all, give nothing" license: AMD consumes the work done by countless individuals and other companies, adds their 1% of value - and does not give it back. A good example why the GPL does have to be as restrictive as it is. Otherwise you always have those .... who behave like this.
        Conversely, LLVM having an overly permissive license allows AMD to try experimental things in their various software and AOCC releases and then push upstream to LLVM what works without worrying about violating licenses and running afoul of the law. It also allows them to put their closed source bits in their released binaries. That's something that using the GPL would prevent. Not using the GPL has another benefit by allowing them to work with more open source licenses and projects. When you're working with closed source software and other non-GPL software, using the GPL can be a burden.

        That overly permissive license is what allows them to release AOCC under its restrictive license. Licensing can be funny like that.

        This isn't one of those times where I'm intentionally trying to be anti-GPL. When you're starting out fresh with no attachments then the GPL can be a great choice. When you have strings attached and want to convert as much as you can, when you can (like once a patent expires) to open source then the GPL might be a choice that can't even be considered.

        I'd like to think that they'll eventually be free of those strings and release their code as GPL.

        Comment


        • #5
          Originally posted by skeevy420 View Post


          Conversely, LLVM having an overly permissive license allows AMD to try experimental things in their various software and AOCC releases and then push upstream to LLVM what works without worrying about violating licenses and running afoul of the law. It also allows them to put their closed source bits in their released binaries.
          amd could do the same things with gcc as well, the only difference being that the gpl requires them to make their diff to the base gcc version available as well in case they release it to the public. Hardly an obstacle when you have a vcs, and do not depend on separately licensed third party bits.
          Last edited by mlau; 11 October 2024, 11:17 AM.

          Comment


          • #6
            That would be great ! to see - very interesting, how much effort & skill AMD put into their own compiler. I remember from previous Phoronix tests over the years - results were a "mixed bag".

            Comment


            • #7
              Originally posted by Linuxhippy View Post
              and does not give it back.
              That's a complete lie, but something I expect around here.

              Comment


              • #8
                It seems like a lot less effort to get their patches upstreamed into the LLVM project than publishing their own fork... why AMD? Why?

                Comment

                Working...
                X