Announcement

Collapse
No announcement yet.

The Gaming Performance Impact From The Intel JCC Erratum Microcode Update

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

  • The Gaming Performance Impact From The Intel JCC Erratum Microcode Update

    Phoronix: The Gaming Performance Impact From The Intel JCC Erratum Microcode Update

    This morning I provided a lengthy look at the performance impact of Intel's JCC Erratum around the CPU microcode update issued for Skylake through Cascade Lake for mitigating potentially unpredictable behavior when jump instructions cross cache lines. Of the many benchmarks shared this morning in that overview, there wasn't time for any gaming tests prior to publishing. Now with more time passed, here is an initial look at how the Linux gaming performance is impacted by the newly-released Intel CPU microcode for this Jump Conditional Code issue.

    http://www.phoronix.com/vr.php?view=28466

  • #2
    Originally posted by phoronix View Post
    Phoronix: The Gaming Performance Impact From The Intel JCC Erratum Microcode Update

    While Intel engineers are working on toolchain updates for working around the issue -- and generally working well as shown in the tests earlier ...

    http://www.phoronix.com/vr.php?view=28466
    In my opinion, Intel made a very serious, completely avoidable, mistake in the design of their Skylake-based CPUs. One of their solutions is to patch compiler toolchains. Enabling the patch will affect about 99% of x86 applications because a jump instruction image crossing a 32-byte boundary or ending on a 32-byte boundary has probability close to 100% to appear in an x86 application at least once. Developers who are conscious about the quality of their software will be forced to pass special flags to the toolchain which will slightly slow down or increase the codesize of future applications on all non-Intel CPUs and on all Intel CPUs without the erratum. Because this is an avoidable erratum which should have been detected during CPU design validation, patching the toolchain is quite unusual.

    The other solution, to let Intel CPU users to update microcode in their machines, is fine because it does not slow down non-Intel CPUs nor Intel CPUs without the erratum.

    Comment


    • #3
      Michael

      Thanks for pointing out the higher frame-times!

      As if the situation wasn't already bad enough with these...

      Still, all the more reason to run a "lowlatency" kernel to, wait for it, 'mitigate' the higher frame-times! (See what I did there?)

      Comment


      • #4
        Originally posted by atomsymbol View Post

        In my opinion, Intel made a very serious, completely avoidable, mistake in the design of their Skylake-based CPUs. One of their solutions is to patch compiler toolchains. Enabling the patch will affect about 99% of x86 applications because a jump instruction image crossing a 32-byte boundary or ending on a 32-byte boundary has probability close to 100% to appear in an x86 application at least once. Developers who are conscious about the quality of their software will be forced to pass special flags to the toolchain which will slightly slow down or increase the codesize of future applications on all non-Intel CPUs and on all Intel CPUs without the erratum. Because this is an avoidable erratum which should have been detected during CPU design validation, patching the toolchain is quite unusual.

        The other solution, to let Intel CPU users to update microcode in their machines, is fine because it does not slow down non-Intel CPUs nor Intel CPUs without the erratum.
        I don't think bullshit like "let's recompile all software to fix hardware issues" should go down. This is a hardware problem, so either load updated microcode and suck it, or change the CPU/system.

        Comment


        • #5
          Michael

          I noticed that except for Total War you benchmarked all the games at 1440 or 2160 (that might leave some of the games GPU bound), so if you're looking at the impact of a CPU only change, the full effect might be more noticeable at 1080p.

          Comment


          • #6
            Most of the testing was done at 1440p or 4k and RTX 2080 Super. This means that a lot of the results can be actually GPU-bound. The results would be more informative and reliable if they were done at 1080p and using RTX 2080 Ti to minimize any GPU bottlenecks.

            Comment


            • #7
              Originally posted by atomsymbol View Post

              In my opinion, Intel made a very serious, completely avoidable, mistake in the design of their Skylake-based CPUs. One of their solutions is to patch compiler toolchains. Enabling the patch will affect about 99% of x86 applications because a jump instruction image crossing a 32-byte boundary or ending on a 32-byte boundary has probability close to 100% to appear in an x86 application at least once. Developers who are conscious about the quality of their software will be forced to pass special flags to the toolchain which will slightly slow down or increase the codesize of future applications on all non-Intel CPUs and on all Intel CPUs without the erratum. Because this is an avoidable erratum which should have been detected during CPU design validation, patching the toolchain is quite unusual.

              The other solution, to let Intel CPU users to update microcode in their machines, is fine because it does not slow down non-Intel CPUs nor Intel CPUs without the erratum.
              There's a chance that the offending jump will occur in parts of the code that are not performance sensitive, and might even be executed just once. There's also the problem of new toolchain generating code where hot parts of it don't fit in the code cache, causing more significant performance penalties.

              The fact that Intel thought it would be a good idea to "fix" this problem by posting patches to GAS is ridiculous, and I hope proprietary software won't be built with these mitigations enabled. Not every Intel chip is affected by this, so they're shooting themselves in their foot, but also other chips are taking the hit as well.

              I think Intel should consider putting more money into validating their designs before shitting them out to the market, as it will probably cost them less than spending all that effort on handling the mess they've made for themselves. I guess that layoff they had a couple of years ago really paid off with the nightmare they made for themselves.

              Comment


              • #8
                Originally posted by DoMiNeLa10 View Post
                The fact that Intel thought it would be a good idea to "fix" this problem by posting patches to GAS is ridiculous, and I hope proprietary software won't be built with these mitigations enabled. Not every Intel chip is affected by this, so they're shooting themselves in their foot, but also other chips are taking the hit as well.
                In my opinion, it doesn't matter whether not every Intel chip is affected by this. A developer in many cases doesn't have control over which CPU is in the user's machine. From the viewpoint of a developer, if for example just 5% of users are estimated to be running the software on affected Intel CPUs then this relatively small percentage translates into a necessity to compile the software with the patched toolchain.

                Like in the case of CONFIG_RETPOLINE, the Jcc erratum is a compile-time option that, under normal conditions, cannot be dynamically turned off/on at will during runtime. This means that distributions like Ubuntu will need to - if Ubuntu maintainers decide that the Jcc erratum is significant enough - compile the default Ubuntu kernel with the patched toolchain and with the new -mbranches-within-32B-boundaries option. It is possible, though unlikely in my opinion, that Ubuntu/etc will decide to start distributing two distinct x86 kernel images - one for affected Intel CPUs and the other one for unaffected AMD/Intel CPUs - and let the bootloader (such as grub) decide which kernel to load based on probing the CPU for vulnerabilities (but this step would of course require patches enabling the bootloader to be able to perform such decisions, including the ability for the bootloader to update the CPU's microcode). Another option would be for the Linux kernel itself to contain multiple versions of the whole kernel, each one compiled with different compiler options. This would ensure that every user gets the best performance out of the kernel and does not need to resort to using a kernel statically compiled for the worst case scenario.

                Comment


                • #9
                  Originally posted by StephenL View Post

                  I noticed that except for Total War you benchmarked all the games at 1440 or 2160 (that might leave some of the games GPU bound), so if you're looking at the impact of a CPU only change, the full effect might be more noticeable at 1080p.
                  Originally posted by fintux View Post
                  Most of the testing was done at 1440p or 4k and RTX 2080 Super. This means that a lot of the results can be actually GPU-bound. The results would be more informative and reliable if they were done at 1080p and using RTX 2080 Ti to minimize any GPU bottlenecks.
                  Notice that all of the tests achieved a framerate higher than 60 Hz. With FreeSync, a game needs only about 50 Hz to appear smooth to most gamers. For the most part, anything higher than 60 Hz is an unnecessary waste of electrical energy and increases fan noise, unless the gamer is using a 100+ Hz monitor and gains an actual advantage from using the 100+ Hz refresh rate. (I do not own a 144 Hz display, so I what I wrote may be completely invalid.)

                  Comment


                  • #10
                    Originally posted by atomsymbol View Post

                    In my opinion, it doesn't matter whether not every Intel chip is affected by this. A developer in many cases doesn't have control over which CPU is in the user's machine. From the viewpoint of a developer, if for example just 5% of users are estimated to be running the software on affected Intel CPUs then this relatively small percentage translates into a necessity to compile the software with the patched toolchain.

                    Like in the case of CONFIG_RETPOLINE, the Jcc erratum is a compile-time option that, under normal conditions, cannot be dynamically turned off/on at will during runtime. This means that distributions like Ubuntu will need to - if Ubuntu maintainers decide that the Jcc erratum is significant enough - compile the default Ubuntu kernel with the patched toolchain and with the new -mbranches-within-32B-boundaries option. It is possible, though unlikely in my opinion, that Ubuntu/etc will decide to start distributing two distinct x86 kernel images - one for affected Intel CPUs and the other one for unaffected AMD/Intel CPUs - and let the bootloader (such as grub) decide which kernel to load based on probing the CPU for vulnerabilities (but this step would of course require patches enabling the bootloader to be able to perform such decisions, including the ability for the bootloader to update the CPU's microcode). Another option would be for the Linux kernel itself to contain multiple versions of the whole kernel, each one compiled with different compiler options. This would ensure that every user gets the best performance out of the kernel and does not need to resort to using a kernel statically compiled for the worst case scenario.
                    Compiling multiple binaries for different CPUs is quite normal, and there is software out there that does that just to be able to take advantage of newest instructions in a CPU, while providing other ones for legacy chips. Having a JCC patched version of proprietary software only for affected chips would be a win for everyone. Binaries themselves aren't that big.

                    When it comes to distros, compiling all software twice is a different problem entirely. The best thing would be to tell affected people to install Gentoo with correct build flags and screw off, that way noone has to babysit people who were unfortunate enough to buy these shitty chips.

                    Comment

                    Working...
                    X