So this week, there’s been a fair amount of news about Meltdown & Spectre exploits, which affects all major processor vendors one way or another, but especially Intel, and whose mitigations require operating systems and in some case microcode updates that decrease performance for some specific tasks.
Microsoft has now pushed an update for Windows 10, and since I’m reviewing MINIX NEO N42C-4 mini PC powered by an Intel Pentium N4200 “Apollo Lake” processor, and just happened to run benchmarks before the update, so I decided to run some of the benchmarks again to see if there was any significant difference before and after the security update.
First I had to verify I had indeed received the update in the “installed update history”, and Windows 10 Pro was updated on January 5th with KB4056892, which is what we want, so let’s go ahead.
Benchmarks before Update
PCMark 10 is one of my favorite benchmark since it relies on typical program that many people would use on their desktop computer.
Let’s through 3DMark Sky Diver to get some 3D graphics performance.
Finally, I’ve run CrystalDiskMark to test I/O performance of the internal eMMC flash.
Benchmarks after Update
Let’s see if there are any significant differences, bearing in mind there’s always some variation for each benchmark run.
Right the score is lower, but it’s really insignificant, and represents at 0.63% decrease in performance, which should likely have nothing to do with the update. So no difference before and after update here.
Same story for 3DMark Sky Diver 1.0, basically the same score as before the update. Link to 3DMark result.
There’s normally a lot more variation for I/O benchmarks like CrystalDiskMark, so results are a bit more difficult to analyze, and have both screenshot side-by-side. We can safely say there’s no difference for sequential read/write (Seq Q32T1 & Seq), and I even got slightly better numbers after the updates. Random I/O look fairly good after the update, except for “4K Read” test. I repeated it several times, and always got 14 to 17 MB/s after the update (23 to 37% slower), while the “4K write” was always higher. This should not matter to most use cases.
At this stage, I was expecting to draw a table showing a 5% difference after the update, but I won’t, because there’s no clear performance hit after the update, despite Apollo Lake architecture being impacted by Meltdown and Spectre. Maybe some other database specific tests would have shown a difference, or the security fixes may mostly impact the performance of higher-end processors.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
thank you for clearing this up
i was kinda worried
They are in-order cores. There wouldn’t be a performance impact because there’s no speculative OoO execution for Meltdown.
Atom processors have featured OoO since Silvermont, in 2013.
https://www.cnx-software.com/2013/05/07/intel-takes-on-arm-with-silvermont-microarchitecture-for-low-power-socs/
I am waiting to see benchmarks in high end cpus that it will be greater the numbers.
@Charlie
TechSpot did some tests with an Intel Core i7-8700K processor @ https://www.techspot.com/article/1554-meltdown-flaw-cpu-performance-windows/, and against in most cases no different, except for random reads.
@Da Xue
Speculative execution is not limited to OoO.
Here are some other bench
https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update
Default RAM / eMMC?
He-he, try to measure power consumption and CPU temp before update and after 😉 Some people saying that they raised up to 30%…
@blu
Speculative execution is indipendent from OoO but often if not always all InOrder processors are without speculative execution.
Then in the world there are Out of Order processor with speculative execution and others (sure for not Intel cpu, I don’t know if exist some Intel OoO procs without SpEx) without.
For the bug we need speculative execution (probably with OoO) and some type of cache management.
Dear
Nice to see you.
@Fabry
Please, name one in-order CPU without a branch predictor.
Apparently compilation jobs are hit the most.
Branch prediction doesn’t imply speculative execution. ARM in-order cores (A7, A53, etc.) will just flush the first 4 stages of the pipeline if the branch was mispredicted. The pipeline might be stalled but instructions won’t be speculatively issued on those cores.
@Bogolisk
Whereas other pipelines do not flush (parts of) their pipelines if a branch is mispredicted? You lost me here.
How do you know KB4056892 has the correct patch? I don’t see it mentioned anywhere here:
https://support.microsoft.com/en-us/help/4056892/windows-10-update-kb4056892
@Bogolisk
Or are you saying that the branch predictor will merely direct the fetch logic for the duration of the next 4 clocks and then pipeline will stall to wait for the branch resolve? If so, have you actually tested that?
@Bogolisk
Seems to me like a branch mispredict flushes effectively the complete A53 pipeline:
http://www.7-cpu.com/cpu/Cortex-A53.html ^f ‘Branch misprediction penalty’ (for an integer pipeline length of 8).
If that’s the case then A53 does execute speculatively beyond the branch point, but not necessarily with loads/stores (which is what most likely helps it in the Specter case, where other in-orders like A8 are vulnerable).
@Bogolisk
Some food for thought: https://pastebin.com/TXtsuPvs
blu : @Bogolisk Whereas other pipelines do not flush (parts of) their pipelines if a branch is mispredicted? You lost me here. OoO : will speculatively issue instructions, mispredicted instructions will be removed before completion. speculative instructions are executed but will not complete (no result write-back) if mispredicted. Data can still be loaded from memory (and fill the cache) but not stored in destination register if mispredicted. in-order: will speculatively fetch and decode instructions but will NOT issue speculative instructions. speculative instructions are not allowed to reach the exec stage of the pipeline. there’s no speculative data load from memory.… Read more »
Branch prediction is typically used on non-speculative architectures in order to avoid pipeline bubbles. InOrder cpu can be speculative (and maybe many of them are speculative now) but since they are in order the speculative instructions never should be completed. The fact that jump has been mispredicted is known (if pipeline is long enough) before the first speculative instruction leaves the pipeline or at least reach the load/store stage. In OutOfOrder cpu the speculative instructions could be completed executed before the misprediction has been discovered. The bug needs that speculative instructions are completed executed or at least they reach the… Read more »
@Fabry
because the a8 issues speculative instructions while the a7 and a53 will stall if necessary. The misprediction penalty on the A8 is 9 cycles including the 5 execution stages E0 to E4 (E5 is completion).
What I don’t understand is: Spectre could trick the victim to load data from RAM to the cache-line. But secrets are usually in private-mapped page. How does attacker read private page or its cache without root?
@Drone
Check the third link “update for Windows 10” in the introduction, it refers to (KB) 4056892 to mitigate the issue for Internet Explorer, Microsoft Edge, and Windows 10.
Bogolisk : OoO : will speculatively issue instructions, mispredicted instructions will be removed before completion. speculative instructions are executed but will not complete (no result write-back) if mispredicted. Data can still be loaded from memory (and fill the cache) but not stored in destination register if mispredicted. in-order: will speculatively fetch and decode instructions but will NOT issue speculative instructions. speculative instructions are not allowed to reach the exec stage of the pipeline. there’s no speculative data load from memory. There’s nothing in the principle of in-order CPUs that dictates in-order CPUs cannot speculate in-order, until a branch is resolved… Read more »
If by ‘completely executed’ you mean their registers written back and the ops retired — that cannot happen, either in OoO or in in-order.
I concede that branch prediction alone does not indicate a pipeline can speculatively execute ops — its speculation might end at decode. But at the opposite end of spectrum sits the statement that an in-order pipeline cannot execute ops speculatively, which is another overgeneralisation.
blu : Bogolisk : OoO : will speculatively issue instructions, mispredicted instructions will be removed before completion. speculative instructions are executed but will not complete (no result write-back) if mispredicted. Data can still be loaded from memory (and fill the cache) but not stored in destination register if mispredicted. in-order: will speculatively fetch and decode instructions but will NOT issue speculative instructions. speculative instructions are not allowed to reach the exec stage of the pipeline. there’s no speculative data load from memory. There’s nothing in the principle of in-order CPUs that dictates in-order CPUs cannot speculate in-order, until a branch… Read more »
@Bogolisk
While on the subject of A8, ARM state the branch misprediction penalty on the A8 as 13 clocks: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344i/Cacgacec.html
And I’m still interested to hear why you think A53 flushes just the first 4 stages, given its misprediction penalty is 7 clocks.
No for “completely executed” I just meant that they could have completely used the execution units or load / store units and are now in the Ready To Retire stage where they wait for time to commit.
Commit can not be already done because in OutOfOrder processors it is only the execution that is out of order, the commit is always for sure In Order.
Furthermore, before the commit can take place the mis-prediction will be known and the speculative instructions deleted from the commit queue (ROB ReOrder Buffer).
@Fabry
Ok, I just had to make sure we talking the same things.
BTW, so that readers don’t get the impression that A8 is some weird-freak-of-nature in-order design that executes speculatively against all norms, here’s another good read on speculatively-executing in-order desings: https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/
Bogolisk : Bogolisk : Thus, in-order CPUs with branch predictor will not speculative execute anything. Is the A8 by mistake on the list? No, but the A8 seems to be the only in-order ARM core that issues speculative instructions. Are you saying that based solely on the Spectre info? A8 is the only in-order ARM core that is susceptible to Spectre; whether it’s the only ARM core that issues speculatively cannot be derived from the Spectre info alone. And since posts on wordpress’ can appear with arbitrary delays, I’ll reiterate my question in case you missed it: I’m still interested… Read more »
@Jean-Luc Aufranc (CNXSoft) “@Drone, Check the third link “update for Windows 10” in the introduction, it refers to (KB) 4056892 to mitigate the issue for Internet Explorer, Microsoft Edge, and Windows 10.” Nope, that link first takes me to a EULA page then to a generic “Security Update Guide” lookup page. So I search for 4056892 and finally I find the links for Explorer, Edge, and Windows 10. But for 64-bit Windows 10 there’s no specific mention of the Meltdown\Spectre issue, not even the CVE. I’ve seen this KB4056892 on other sites too, but nobody has been able to point… Read more »
@Drone
OK, that’s crazy. But apparently you need to click on the “update for Windows 10” link, accept the EULA which will take you to the generic Security Update Guide you mentioned, and then click on the first link again, and you should access “ADV180002 | Guidance to mitigate speculative execution side-channel vulnerabilities”.
Intel has also released their own number for Intel Core i7 benchmarks before and after the meltdown/spectre fix
https://newsroom.intel.com/editorials/intel-security-issue-update-initial-performance-data-results-client-systems/
because that’s what ARM said in A53 doc (no link sorry). Something like the core will stall so it’s up to up the compiler to prevent pipeline hazards…
Oh the fun of updates 😉
Intel’s patches for its processor bugs are themselves buggy.
It is reported that datacentres have been told to delay installing them, while Intel issues patches to patch the patches.
“We are working quickly with these customers to understand, diagnose and address this reboot issue,” says Navin Shenoy, GM of Intel’s data centre groupsaid in the statement. “If this requires a revised firmware update from Intel, we will distribute that update through the normal channels.”