Announcement

Collapse
No announcement yet.

Intel's Assembler Changes For JCC Erratum Are Not Hurting AMD

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

  • Intel's Assembler Changes For JCC Erratum Are Not Hurting AMD

    Phoronix: Intel's Assembler Changes For JCC Erratum Are Not Hurting AMD

    When writing about the Intel Jump Conditional Code (JCC) Erratum and how Intel is working to mitigate the performance hit of the CPU microcode update with patches to the GNU Assembler, there was some concern expressed by readers that it might hurt AMD performance. That does not appear to be the case...

    http://www.phoronix.com/scan.php?pag...-JCC-Assembler

  • #2
    Proof that AMD has already beaten Intel.

    Comment


    • #3
      The idea that everyone will add arbitrary restrictions on how to generate machine code just to ensure certain Intel chips don't get a slight performace loss with patched microcode is insane. Even if it doesn't seem to affect performance much, it's just a backwards idea to take CPU bugs in some Intel chips as a reason to patch the toolchain.

      Comment


      • #4
        Originally posted by DoMiNeLa10 View Post
        The idea that everyone will add arbitrary restrictions on how to generate machine code just to ensure certain Intel chips don't get a slight performace loss with patched microcode is insane. Even if it doesn't seem to affect performance much, it's just a backwards idea to take CPU bugs in some Intel chips as a reason to patch the toolchain.
        This mitigation is functionally a microarchitecture-specific optimisation, that does not seem to have adverse effects on microarchitectures that don't benefit from it. GCC is already full of these march specific optimisations, eg. see -march and -mtune.

        Comment


        • #5
          Intel's Assembler Changes For JCC Erratum Are Not Hurting AMD
          Nonsense. They do not hurt in case you comple with Zen2 target, but almost all software is compiled/linked for generic x86_64 - where you have those stupid workarrounds resulting in non-optimal code for executed by all platforms, just to avoid bugs on the Intel models.

          For Intel-CPUs enabling code-gen workarrounds has always been out of question, I wonder what would happen in case AMD would require such workarrounds one day - would distributions/compilers decide to penalize Intel CPUs in order to work arround issues on AMD ones? Monopoly works.

          Comment


          • #6
            Oh right, even though it's not much then why does the right hand side of the table shows a marked regression after the patch?
            That's more than statistical error....

            Intel dragging the ship down with it due to laziness aka plausibly deniable anti-competitive practices.
            Guess in future you need to bench with the pre-patch version?

            Comment


            • #7
              Originally posted by Linuxhippy View Post
              Nonsense. They do not hurt in case you comple with Zen2 target, but almost all software is compiled/linked for generic x86_64 - where you have those stupid workarrounds resulting in non-optimal code for executed by all platforms, just to avoid bugs on the Intel models.
              Where are your benchmarks showing it to be nonsense?

              The benchmark in the article was compiled with -mtune=skylake btw.

              Comment


              • #8
                I'm so genuinely happy i took that Ryzen 5 2600 for 120$ and didn't brain fart and went with something from Intel, my poor Xeon E3 1231v3(office WS) is suffering enough as it is and ironically need less mitigations than Skylake++++++++++

                Comment


                • #9
                  Originally posted by log0 View Post
                  Where are your benchmarks showing it to be nonsense?

                  The benchmark in the article was compiled with -mtune=skylake btw.
                  Majority of software is compiled WITHOUT -march.

                  They must patch generic codegen to protect against this bug (we dont know where the resulting binary will run) too - perf loss for all.

                  Comment


                  • #10
                    Originally posted by airminer View Post

                    This mitigation is functionally a microarchitecture-specific optimisation, that does not seem to have adverse effects on microarchitectures that don't benefit from it. GCC is already full of these march specific optimisations, eg. see -march and -mtune.
                    no, it is not an optimization, it is a workaround for a really silly bug. If all CPUs would be so buggy and each vendor would like to have such crappy (32 byte alignment seriously) workarounds in the assembler, gcc/binutils would barely be able to still generate code at all. IMHO such crippling workaround should not be added to the toolchain at all, and vendors fix this bugs in the CPUs and microcode themselves. Maybe better ramp up their QA efforts and btw. users should demanded fixed silicon.
                    Last edited by rene; 11-14-2019, 10:34 AM.

                    Comment

                    Working...
                    X