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 phoronix View Post
      Granted, 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
      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
      Last edited by atomsymbol; 06-28-2020, 05:07 AM.

      Comment


      • #13
        Originally posted by atomsymbol View Post
        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


        • #14
          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


          • #15
            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


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

              Comment


              • #17
                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


                • #18
                  Originally posted by ktecho View Post

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

                  Comment


                  • #19
                    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


                    • #20
                      Originally posted by dev547 View Post
                      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)
                      You are right in the sense that a minimal upgrade from FM2+DDR3 to AM4+DDR4 means about 150€, assuming new (unused) components.

                      A puzzling question is whether to upgrade to Zen3 (DDR4) or wait for the first DDR5 (AMD or Intel) benchmarks which are likely to be published in the second half of 2021. 1 channel of [email protected] is, roughly speaking, equivalent to 1.5 channels of [email protected], so a dual channel DDR5 is equivalent to a 3-channel DDR4, which might help highly parallel workloads limited by dual-channel DDR4 memory.
                      Last edited by atomsymbol; 06-28-2020, 12:23 PM. Reason: Add minimal

                      Comment

                      Working...
                      X