Slashdot Mirror
Microsoft Details Performance Impact of Spectre and Meltdown Mitigations on Windows Systems (microsoft.com)
Microsoft's Windows chief Terry Myerson on Tuesday outlined how Spectre and Meltdown firmware updates may affect PC performance. From a blog post: With Windows 10 on newer silicon (2016-era PCs with Skylake, Kabylake or newer CPU), benchmarks show single-digit slowdowns, but we don't expect most users to notice a change because these percentages are reflected in milliseconds.
With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and we expect that some users will notice a decrease in system performance. With Windows 8 and Windows 7 on older silicon (2015-era PCs with Haswell or older CPU), we expect most users to notice a decrease in system performance.
Windows Server on any silicon, especially in any IO-intensive application, shows a more significant performance impact when you enable the mitigations to isolate untrusted code within a Windows Server instance. This is why you want to be careful to evaluate the risk of untrusted code for each Windows Server instance, and balance the security versus performance tradeoff for your environment.
For context, on newer CPUs such as on Skylake and beyond, Intel has refined the instructions used to disable branch speculation to be more specific to indirect branches, reducing the overall performance penalty of the Spectre mitigation. Older versions of Windows have a larger performance impact because Windows 7 and Windows 8 have more user-kernel transitions because of legacy design decisions, such as all font rendering taking place in the kernel.
With Windows 10 on older silicon (2015-era PCs with Haswell or older CPU), some benchmarks show more significant slowdowns, and we expect that some users will notice a decrease in system performance. With Windows 8 and Windows 7 on older silicon (2015-era PCs with Haswell or older CPU), we expect most users to notice a decrease in system performance.
Windows Server on any silicon, especially in any IO-intensive application, shows a more significant performance impact when you enable the mitigations to isolate untrusted code within a Windows Server instance. This is why you want to be careful to evaluate the risk of untrusted code for each Windows Server instance, and balance the security versus performance tradeoff for your environment.
For context, on newer CPUs such as on Skylake and beyond, Intel has refined the instructions used to disable branch speculation to be more specific to indirect branches, reducing the overall performance penalty of the Spectre mitigation. Older versions of Windows have a larger performance impact because Windows 7 and Windows 8 have more user-kernel transitions because of legacy design decisions, such as all font rendering taking place in the kernel.
Your performance will be fucked six ways to Sunday if your workload does a lot of user to kernel mode switches. Unless you fancy waiting for Intel to release fixed chips and then buying a new CPU and a new motherboard to put it in.
Ironically Intel forcing people to buy new motherboards to switch between very similar CPU generations coupled with the fact that any Intel CPU you buy now still has the bug means that its just as easy to buy an AMD CPU and motherboard than an Intel one.
Then again a new Intel chip has Process Context ID support which means the workaround for the bug is relatively low impact.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Windows 10 sucks (quantify that)
1. Keyloggers that send your keystrokes to Microsoft to serve targets ads in the OS. *cough* I mean 'Telemetry'.
2. Inability to control patches / updates
3. Reduced control over a system I *own*
There's a good start.
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
I am running a Skylake Core i5-6500 with 8GB RAM and a 250GB Samsung SSD with Windows 7 Home Premium and I have the patch installed and haven't observed any slowdowns.
Just kicked of a full compile (in VS 2017) of a large (~2100 files) project I have here and I saw no noticeable slowdowns compared to how fast the thing compiled before the patch. And such a thing would be highly I/O bound (reading all the input source files and things, writing out compiled obj and other files, reading toolchain binaries etc) and likely making a lot of kernel-user transitions.
I have no games on here that are demanding enough to show any observable difference between old and new so I cant test those.