—
Not exactly nice news for Intel 10nm processor owners: both Ice Lake and Tiger Lake have a bug that fixes in microcode slightly reduces performance. But it wouldn’t hurt her.
Before they came out Ryzen processors with Zen 3 architecture, it was probably expected that AMD would not reach IPC (ie power at 1 MHz) Intel Tiger Lake processors and will thus have a lower single-stranded power. In the end, it seems surprisingly balanced (although we’ll see how they turn out Rocket Lake, Tiger Lake-H a mobile Zen 3 from AMD).
This balanced battle (or, let’s say, more balanced for AMD than expected) may also be somewhat helped by the fact that Intel’s new “post-Skylake” processor architectures have now suffered some slowdown. In the cores Sunny Cove a Willow Cove, ie the CPU architectures of the 10nm chips Ice Lake and Tiger Lake, an error was found, due to which Intel had to add one of the functions of the processor by updating the microcode. And this probably leads to some reduction in IPC (and thus overall performance). Fortunately, probably a small one, even given that it was noticeable enough unnoticed.
This bug was documented by Intel as an ICL065 erratum and is probably not completely fresh – the patch microcodes were distributed last November at the latest (and maybe sooner, after a while), but it probably happened without much attention. But now researcher Andreas Abel has been alerted that the fix turns off the so-called Move Elimination feature on Ice Lake.
Erratum ICL065 says that in rare cases, eliminating Move Elimination operations can cause the processor to go crazy – so-called unpredictable behavior, which is typically a crash or freeze. So it’s not about security hole, but about a bug affecting stability, which unfortunately sometimes occurs. The documentation says that the problem can be bypassed using the BIOS, which means that it is probably an update to the CPU microcode that may be wrapped in the BIOS.
What is Move Elimination
Andreas Abel figured out that after this update, the Ice Lake Move Elimination processor will probably stop performing completely, which can be verified by special microbenchmarks (for details, see here, if you are interested). What’s going on? Move Elimination takes advantage of the fact that today’s processors do not have hard-wired architectural registers. Instead, they have a so-called physical register file in which the values are stored and the processor works with “links”. One optimization is possible with such implemented registers. This is because data transfers between registers do not have to actually shuffle data. For example, if an instruction moves data from R8 to R9, the processor only needs to note that the current value in the physical register file should now be understood as the contents of the R9 register – so only the reference changes, not the physical “data location”. This, by the way, is intended to save consumption and, conversely, to improve performance.
And because it’s so simple, this operation doesn’t even have to be performed by the CPU. Out of Order processors have long been performing the so-called renaming of registers, where they internally abstract registers from their architectural names so that they can work with a higher number of registers than, for example, the 16 available for x86-64. This hides some conflicts and speeds up calculations because there is no need to wait for data to be “poured out” of registers into RAM and reloaded.
When the processor has a physical register file with the described referencing system, it is very easy instead of the MOV instruction to simply swap references during the register renaming phase, thus the instruction is executed. This is called Move Elimination. The operation will still take place, but will be handled in the processor pipeline before it should arrive at the computing units. As a result, they are not busy executing MOV instructions and can do something else.
The impact on performance is probably negligible, but it also occurred at Tiger Lake
But in Ice Lake, Intel found a logical bug that probably causes the processor to do wrong with Move Elimination or otherwise do something wrong. This is probably a very rare case due to an unusual interplay of factors, otherwise it would have been discovered much earlier and processor instability would have been observed. But the severity was probably enough to keep this bug uncorrected.
At Ice Lake, therefore, Move Elimination was turned off in the fall (or earlier). This means that MOV instructions moving data between registers will now be processed manually by the computational units, and it will do them some work. Due to the parallelism in the processor, which should often have some free drive for the operation, it should usually not be a big burden. Disabling off also applies to general registers only, not SIMD registers for SSEx, AVX, and AVX-512 instructions. It works there even after the update.
The good news is that although this has some measurable impact on performance, it should be very small – that’s probably why no one noticed things in November and there are no complaints about the slowdown. Those who reported or tested this erratum do not report speed measurements before and after microcode application, but it is estimated that the average deceleration should probably not be more than about one percent – sometimes perhaps slightly above, often below one percent.
Error and correction is possible here since spring?
However, there is a possibility that this discovery of the malfunctioning Move Elimination is in fact a slightly older regression of performance, although it has probably been forgotten a bit and is now being talked about again. A similar microcode update that reduces the performance of Ice Lake processors by about one percent to a few percent was released last spring, we wrote about it, and the Phoronix website then measured the decline in performance:
Tip: Intel has released new CPU microcodes. Fixing an unknown bug seems to slow down the core of Ice Lake
At that time, there was a lack of information as to why performance was reduced. The defect in the Move Elimination mechanism is therefore perhaps a belated explanation. In that case, then, we are now talking again about the same mistake. This is good news, because we are also talking about the same slowdown that has already taken place, and it is not the case that another is coming now to accumulate nicely with the previous one. However, 100% of this old worthless newspaper is not.
The bad news is that the impact of this erratum ICL065 was subsequently confirmed not only in Ice Lake processors, but also in the newer Tiger Lake. According to microbenchmarks, Move Elimination is also disabled on the general registry (it is not clear whether the microcode was also released immediately after the release or update). So last year we talked about the bug as a performance regression on the Ice Lake architecture, which means that Tiger Lake inherited it and Intel didn’t have time to fix it in hardware before it was released. Unfortunately, we now have a secondary message that the current 10nm generation has the same problem / drop in performance.
I Rocket Lake?
It is even possible that the error when porting to a 14nm process was transferred to the incoming Rocket Lake desktop processors, which would also slightly damage the IPC. Again, the impact is almost negligible (if ICL065 is the old problem from last year, then probably that Phoronix test shows what Rocket processors are missing). Perhaps this could be a partial explanation for why Rocket Lake in the benchmarks are not as strong against Zen 3 as expected in the end.
Gallery: Phoronix test showing a drop in Intel Ice Lake processor performance with microcode 0x78
If you own one of the affected processors, there is probably no need to upset the repair. A few percent deterioration in performance shouldn’t really be a problem anywhere. However, if you can’t stand the thought, you can, at least in the case of Ice Lake, load an older BIOS from before November that doesn’t already contain patch microcode. You will gain the lost power in addition, but at the cost of the theoretical risk that you will sometimes encounter that rare instability. According to Travise Downse Move Elimination is still functional with microcode version 0x70.
Of course, it would be ideal if silicon did not have this error, but with today’s complex CPUs it is not possible to achieve complete faultlessness. The combination of all possible states and factors in different situations cannot be tested in advance, so it is inevitable that some design errors will remain and are only detected in the finished chips. Today, CPUs of over a hundred have such errata and are something that one simply has to come to terms with.
Intel is likely to fix the bug in some of the next architectures (perhaps Alder Lake, if not Rocket Lake), so the IPC sanction that has now arisen and will easily help rival AMD will be recovered in future cores.
Gallery: Unveiling of Ice Lake Processors and Sunny Cove Architecture (Computex 2019)
Resources: Intel, Andreas Abel (1, 2)
