Announcement

Collapse
No announcement yet.

LLVM Begins Landing Preliminary Patches Around Intel's JCC Erratum, GAS Support Landed

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

  • LLVM Begins Landing Preliminary Patches Around Intel's JCC Erratum, GAS Support Landed

    Phoronix: LLVM Begins Landing Preliminary Patches Around Intel's JCC Erratum, GAS Support Landed

    Disclosed back in November was the Intel Jump Conditional Code (JCC) erratum affecting Skylake and newer CPUs that could lead to "unpredictable behavior" when jump instructions cross cache lines. Intel issued a CPU microcode update to address the problem at a performance cost, but with some compiler toolchain magic, it's possible to mitigate a good portion of that impact...

    http://www.phoronix.com/scan.php?pag...C-Erratum-Bits

  • #2
    WARNING: This patch is knowingly incorrect in some cornercases
    Yeah that's not acceptable. I can understand if it doesn't bring back full performance, but merging in patches that are known to be buggy is bad.

    To me it sounds like the person just wanted to push their changes in, no matter what.

    Comment


    • #3
      Originally posted by sandy8925 View Post
      Yeah that's not acceptable.
      You could say that about the Intel product to begin with...

      Comment


      • #4
        Intel Corporation should be renamed to Bugtel these days. They are making Pentium days look like heaven in comparison.

        Can't they invest more in QA in their CPUs these days? This is getting ridiculous.

        Comment


        • #5
          As someone that builds a product around Intel Xeon servers (and slowly migrating to AMD Epyc servers *) this is getting ridiculous.
          I find myself constantly being forced to optimize our code just to regain lost performance due to CPU security and bugs mitigation.
          Is Intel hell bent on driving me crazy...?

          * Porting complex software to a new platform is anything but easy. Configurations must be changed, code, especially optimized kernel code, must be rewritten, let alone the fact that both HP and Dell are slow to release Rome servers...

          - Gilboa
          DEV: Intel S2600C0, 2xE5-2658V2, 32GB, 6x2TB, GTX1080, F30/x86_64, Dell UP3216Q 4K.
          SRV: Intel S5520SC, 2xX5680, 36GB, 6x2TB, GTX550, F30/x86_64, Dell U2711.
          WIN: Gigabyte B85M-HD3, E3-1245V3, 32GB, 5x1TB, GTX980, Win10Pro.
          LAP: ASUS Strix GL502V, i7-6700HQ, 32GB, 1TB+256GB, 1070M, F30/x86_64.

          Comment


          • #6
            Originally posted by gilboa View Post
            As someone that builds a product around Intel Xeon servers (and slowly migrating to AMD Epyc servers *) this is getting ridiculous.
            I find myself constantly being forced to optimize our code just to regain lost performance due to CPU security and bugs mitigation.
            Is Intel hell bent on driving me crazy...?

            * Porting complex software to a new platform is anything but easy. Configurations must be changed, code, especially optimized kernel code, must be rewritten, let alone the fact that both HP and Dell are slow to release Rome servers...

            - Gilboa
            It's still x86, and practically supports the same CPU instructions. Anyway, whatever language you're using will happily work on the new hardware as well, at best it requires recompilation.

            The only real "porting" required is basic stuff like making sure you have the correct CPU microcode, and that the kernel you use supports that CPU and some of the motherboard hardware.

            Comment


            • #7
              Originally posted by sandy8925 View Post

              It's still x86, and practically supports the same CPU instructions. Anyway, whatever language you're using will happily work on the new hardware as well, at best it requires recompilation.

              The only real "porting" required is basic stuff like making sure you have the correct CPU microcode, and that the kernel you use supports that CPU and some of the motherboard hardware.
              You are dead wrong.

              When it comes to handling heavy I/O (passive network input), different platforms behave radically different.
              Under load, things like CPU scaling managers and NUMA / PCI-E / CPU topologies makes a huge difference.

              If you trying to shove~200 Gbits down dozens of network devices with no hardware acceleration to speak of, x86 is not x86!

              - Gilboa
              Last edited by gilboa; 12-28-2019, 05:03 AM.
              DEV: Intel S2600C0, 2xE5-2658V2, 32GB, 6x2TB, GTX1080, F30/x86_64, Dell UP3216Q 4K.
              SRV: Intel S5520SC, 2xX5680, 36GB, 6x2TB, GTX550, F30/x86_64, Dell U2711.
              WIN: Gigabyte B85M-HD3, E3-1245V3, 32GB, 5x1TB, GTX980, Win10Pro.
              LAP: ASUS Strix GL502V, i7-6700HQ, 32GB, 1TB+256GB, 1070M, F30/x86_64.

              Comment

              Working...
              X