Slashdot Mirror
Intel Says Chip-Security Fixes Leave PCs No More Than 10% Slower (axios.com)
Intel trying to defuse concern that fixes to widespread chip security vulnerabilities will slow computers, released test results late Wednesday showing that personal computers won't be affected much and promised more information on servers. From a report: The chipmaker published a table of data showing that older processors handled typical tasks 10 percent slower at most, after being updated with security patches. The information covered three generations of processors, going back to 2015, running Microsoft's Windows 10 and Windows 7 computer operating systems. Further reporting: Intel, Microsoft offer differing views on impact of chip flaw
According to their chart, he oldest CPU they tested is 2.5 years old. Giving that some more proactive businesses have a 3+ year retention rate on hardware, "older" is hardly the word i'd use.
After an OSX update a real world compile of a project that takes around two minutes to complete, too almost exactly the same amount of time, or slightly faster... since compilation involves lots of small files and system calls I would expect it to be harder hit than most tasks. However because they had a partial Meltdown patch in around December, not sure if we would see much of an effect... no-one in December complained about slowdowns from the OSX update at that time though either.
I don't think things most people do will be that affected by the patch.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The relevant base to calculate from depends on what you're focused on.
Take an increase of sales tax from 5% to 6%. If you're focused on how much money you're giving to your local government, 20% is the correct figure to use. If you're focused on the effective change in total prices, 1% is the correct figure to use.
What computer users are naturally focused on is the amount of CPU capacity available for work. A 10% reduction in that is significant, but not catastrophic for most users. In fact many might not ever see any perceptible difference. However, in computer performance there is a powerful, non-linear difference between "just barely enough" and "not quite enough" resources. That means some users are bound to experience this marginal reduction in power as a dramatic difference on some workloads.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
So this now puts Intel chips right in line with AMD's Ryzen per-core performance... except Ryzen costs less and delivers more cores.
I wish I'd bought AMD stock two years ago...
Interesting thing is that PCID predates INVPCID. And you can get some of the effects of an INVPCID on a processor which only supports PCID.
I.e.
http://forum.osdev.org/viewtop...
MOV to CR3. The behavior of the instruction depends on the value of CR4.PCIDE:
If CR4.PCIDE = 0, the instruction invalidates all TLB entries associated with PCID 000H except those for global pages. It also invalidates all entries in all paging-structure caches associated with PCID 000H.
If CR4.PCIDE = 1 and bit 63 of the instructionâ(TM)s source operand is 0, the instruction invalidates all TLB entries associated with the PCID specified in bits 11:0 of the instructionâ(TM)s source operand except those for global pages. It also invalidates all entries in all paging-structure caches associated with that PCID. It is not required to invalidate entries in the TLBs and paging-structure caches that are associated with other PCIDs.
If CR4.PCIDE = 1 and bit 63 of the instructionâ(TM)s source operand is 1, the instruction is not required to invalidate any TLB entries or entries in paging-structure caches.
See
https://www.intel.com/content/... page 145
This chap tried it, and apparently it works
http://www.dumais.io/index.php...
I.e. with bit 63 and 0:11 set to PCID a write to CR3 works like INVPCID in processors which don't have INVPCID.
This actually makes a difference. My 2012 Macbook pro has a
I.e. assuming the patches know the bit 63 set in writes to cr3 trick, they should be able to do page table invalidation per PCID even on rather old chips.
It looks like KAISER on Linux supports/will support this
https://github.com/nathanchanc...
https://lkml.org/lkml/2017/11/... [currently down(!) but the title is "Subject [PATCH 4/6] x86/mm/kaiser: Support PCID without INVPCID"]
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;
The main reason that so many people are confused about the difference between Meltdown and Spectre is that Intel has been intentionally trying to conflate the two issues.
Here:
https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf
It's very unlikely Intell had not come across that document given where it appeared.
It's not the only one. Do search at your leisure...