Announcement

Collapse
No announcement yet.

5+ Years Late: LLVM's AMD Excavator Target Was Missing Two Features

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

  • #11
    Originally posted by xxmitsu View Post
    Isn't rdrand buggy and they decided to disable it ? https://www.phoronix.com/scan.php?pa...isable-15h-16h
    From the LKML thread:

    If it is known that the family 15h or family 16h system does not have an RDRAND resume issue or that the system will not be placed in suspend, the "rdrand_force" kernel parameter can be used to stop the clearing of the RDRAND CPUID bit.
    There's a difference between the compiler not supporting it at all and the kernel (optionally) not advertizing it.

    Comment


    • #12
      Originally posted by atomsymbol
      Just a note: Upgrading from Excavator to the cheapest Ryzen 3 1200
      That's true only if you have an AM4-based Bristol Ridge APU.
      But you cannot upgrade older Carrizo-based systems without replacing your mobo and RAM. Also, Carrizo is a mobile APU most of the time)

      Comment


      • #13
        xxmitsu
        The RDRAND instruction in the CPU itself isn't buggy, only the firmware implementations (and AMD obviously did not care to make OEMs implement it correctly).

        Originally posted by phoronix View Post
        if you are making use of AMD Excavator in 2020 I would encourage you to highly consider the latest Zen 2 CPUs or the upcoming Zen 3 for much better performance and power efficiency, but unfortunate it took this long for the LLVM compiler deficiency to be noticed.
        Excavator is still used in the AMD Chromebooks that are sold today, and it was quite recently that Google started selling AMD Chromebooks. Given that Chrome OS uses the LLVM compiler, that may help performance minimally.

        Also Excavator APUs aren't that bad, the CPU has AVX2 support and the GPU is GCN 3, the 4C/4T parts were roughly on par with the 2C/4T Pentiums of their time, and those lacked AVX2.

        Comment


        • #14
          Originally posted by kravemir View Post

          I had developed a toy frontend for LLVM and also a tiny frontend for GCC. It's much more comfortable to use LLVM and it doesn't require to fork the whole jungle, also it doesn't require to work with obscure makefiles. Also, GCC impairs developer's freedom heavily. LLVM is the future of OSS compilers.
          It probably is the future of OSS compilers. But it isn't the past. This omission happened in the past.

          Comment


          • #15
            This is the most cursed article I have read in a long long time.

            Comment


            • #16
              Originally posted by kravemir View Post

              Also, GCC impairs developer's freedom heavily.
              How? Or perhaps you meant it doesn't allow proprietary to leech on it so easily?

              Comment


              • #17
                Originally posted by ktecho View Post

                Or maybe you're 12 years old.
                What does age have to do with it?

                Comment


                • #18
                  Originally posted by kravemir View Post

                  I had developed a toy frontend for LLVM and also a tiny frontend for GCC. It's much more comfortable to use LLVM and it doesn't require to fork the whole jungle, also it doesn't require to work with obscure makefiles. Also, GCC impairs developer's freedom heavily. LLVM is the future of OSS compilers.
                  To address the "developer's freedom" thing for the bazillionth time:

                  copyleft takes away the recipient's freedom to release a proprietary copy or proprietary fork, and the benefit of the license is transitive. That is, if you release something copyleft, and I modify it and release the modified version, and some third person modifies my version or your version and releases it, all of us get access to the modifications.

                  permissive license takes away the developer's freedom to access all of the modifications and improvements other users might make.

                  Neither is "more free" than the other, it's just a question of which set of freedoms you value more. If you just want to use other people's work without giving back, I'd call you a parasite but then, hey, clearly permissive license is the model for you. If you want everyone that uses the software to benefit from the work that anyone does with it, then copyleft is the way to go.

                  And before someone says it: no, copyleft is not anti-capitalist. It just switches the software industry business model away from paying for copyrighted work towards paying for labor. Instead of buying a proprietary LLVM front-end from you, I just pay you to write and release under the GPL a GCC front end.

                  Comment


                  • #19
                    Originally posted by Michael_S View Post

                    To address the "developer's freedom" thing for the bazillionth time:

                    copyleft takes away the recipient's freedom to release a proprietary copy or proprietary fork, and the benefit of the license is transitive. That is, if you release something copyleft, and I modify it and release the modified version, and some third person modifies my version or your version and releases it, all of us get access to the modifications.
                    Releasing a closed fork of something given to you freely is not "freedom", it's abusing others' goodwill.
                    The GPL license explicitly closes the loophole for this kind of abuse and forces you to reciprocate the goodwill.

                    It's almost the same for LGPL which has the "usage only" (i.e. linkage) excuse: if your code links to it, your code may stay under a different license.
                    But it you changed the library code itself licensed under LGPL, you have to publish the changes according to the license.

                    Originally posted by Michael_S View Post
                    permissive license takes away the developer's freedom to access all of the modifications and improvements other users might make.
                    A permissive license (MIT, BSD) just says that the author doesn't really care about the code, only about attribution.
                    The code may as well be placed in public domain and f*ck attribution.

                    Originally posted by Michael_S View Post
                    Neither is "more free" than the other, it's just a question of which set of freedoms you value more. If you just want to use other people's work without giving back, I'd call you a parasite but then, hey, clearly permissive license is the model for you. If you want everyone that uses the software to benefit from the work that anyone does with it, then copyleft is the way to go.

                    And before someone says it: no, copyleft is not anti-capitalist. It just switches the software industry business model away from paying for copyrighted work towards paying for labor. Instead of buying a proprietary LLVM front-end from you, I just pay you to write and release under the GPL a GCC front end.
                    Very true. One small detail, though: a GPL-ed software may well be licensed for a fee. The source code being free to tinker with is just part of the deal.
                    Also, no one stops you from dual licensing for different use cases.

                    Comment


                    • #20
                      Originally posted by atomsymbol
                      Just a note: Upgrading from Excavator to the cheapest Ryzen 3 1200 (Zen1, 50-60€) is capable of increasing performance by a factor of 2, both in single-threaded and multi-threaded workloads. https://browser.geekbench.com/v5/cpu...seline=2699707
                      you upgrading fm2 to am4 will cost you many times more than that.

                      Comment

                      Working...
                      X