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

  • atomsymbol
    replied
    Originally posted by schmidtbag View Post
    Yes, the GPU is a bottleneck in a lot of these cases. But despite this, we have still seen performance drops. It's good to see 1440p and 4K results, so people playing games at those resolutions know they don't really have anything to worry about. But I agree seeing 1080p results would be nice, since some people prefer higher frame rates over resolution (I personally am not one of them).
    Just a note: An average/median Linux user would experience the effects of the mitigation somewhat differently than in the article. The article uses Core i9-7960X 4.2-4.4 GHz 16/32 cores/threads, which isn't representative of an average/median Intel Linux user. Most people have slower CPUs than i9-7960X: if for example their CPU is 50% slower than i9-7960X it means that the microcode update might have about 50% more severe impact - but only if some OS thread was already near 100% CPU usage and due to microcode update it crosses the threshold of 100% CPU usage while benchmarking the game. In other words, games in the article that for example do not to experience any slowdown from the microcode update might in certain other hardware setups experience a slowdown of a few percent. It would be of great help if the article was measuring the CPU time consumed by each of the benchmarks.

    Leave a comment:


  • schmidtbag
    replied
    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.
    Yes, the GPU is a bottleneck in a lot of these cases. But despite this, we have still seen performance drops. It's good to see 1440p and 4K results, so people playing games at those resolutions know they don't really have anything to worry about. But I agree seeing 1080p results would be nice, since some people prefer higher frame rates over resolution (I personally am not one of them).

    Leave a comment:


  • atomsymbol
    replied
    Originally posted by DoMiNeLa10 View Post
    Having a JCC patched version of proprietary software only for affected chips would be a win for everyone. Binaries themselves aren't that big.
    An example: Shadow of the Tomb Raider executables+libraries have size of about 262 MiB (Linux) and 278 MiB (Windows).

    Leave a comment:


  • fintux
    replied
    Originally posted by atomsymbol View Post
    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.)
    Well then the recent Intel CPU's don't have even the gaming excuse to be bought, as that's the only area where they are having some small frame-rate advantage over AMD. Even that's mostly the case only with 9900K + 2080 Ti. Any slower GPU will be the bottleneck in several games even with slower CPUs. And on 2080 Ti, 3900X (even 3700X) is usually within a few percents of the 9900K, so there's no point paying more for the CPU with security flaws, producing more heat and no platform upgrade path.

    Because the human eyes don't see frames, there are things like ghosting and blurring even with higher than 60 FPS. See for example this: https://www.testufo.com/eyetracking - how different the background looks depending on which UFO you are focusing your eyes to. And blurbusters.com has much more interesting content explaining why things matter beyond 60 Hz (and even beyond 144 Hz).

    Also, any benchmarks on current game mean that a future CPU-bound game would suffer this in similar ratio. So it could be a difference between say, 57 and 60 Hz, which would matter especially without FreeSync. Also, this will likely effect CPUs like older i3, i5 etc., where the starting frame-rate would not be this high. It's also worth pointing out that these changes again further decrease the performance that has already taken hit by the numerous earlier patches to flaws in the Intel CPUs.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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.

    Leave a comment:


  • atomsymbol
    replied
    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.)

    Leave a comment:


  • atomsymbol
    replied
    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.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    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.

    Leave a comment:


  • fintux
    replied
    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.

    Leave a comment:


  • StephenL
    replied
    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.

    Leave a comment:

Working...
X