Intel Performance Hit 5x Harder Than AMD After Spectre, Meltdown Patches
extremetech.com
extremetech.com
They are on track to have an amazing year with CPUs that may take a very significant chunk of the cloud compute away from intel and then maybe even on the performance side.. it’s just fascinating that a company that almost died just a few years ago is now a big contender on multiple fronts.
>The Athlon 1.4GHz is far and away the fastest PC processor you can buy. Well, OK, it's not that much faster than the 1.33GHz Athlon, but it's a heap faster than Intel's 1.7GHz Pentium 4. Through a range of tests measuring a variety of applications and abilities, every one of our Athlons from 1.2GHz to 1.4GHz beat out the Pentium 4 with regularity."[1]
[1] https://techreport.com/review/2523/amd-athlon-1-4ghz-process...
It is happening again, Intel has been sitting on 14nm for 5 years, and now with many security issues and they won't be able to react with 10nm until early next year, and even the 10nm CPU will likely not have a hardware fix. Last time this happen Intel started a price war and FUD against AMD.
The timeline somehow always synced when AMD executed their plan to perfection and Intel somehow messes up at the same time. And then Intel woke up, last time it was Pat Gelsinger who saved them ( And later forced out of Intel ), and then somehow AMD make some missteps. This time Intel got Jim Keller, I hope Dr Lisa Su wont repeat the same mistake again.
Intel did this with P4 "netburst" architecture. They hit a frequency wall that made thier new deeply pipelined CPU worthless. This is when AMD caught up last time with the athlon series.
Intel actually went back to the design of the Pentium III!! With higher IPC, a few upgrades lifted from the P4, and new processes, it gave birth to the Core series.
The Intel processors we have today still share more design history with the P3 than the P4. And since then, Intel has focused on IPC over clock speed.
The crazy part was AMD making the same mistake years later with Bulldozer. Makes me wonder if the remedy was the same... Go back and update the Athlon cores.
The ancient Athlon/P3 IPC is amazingly good compared to today's chips if you scale them by clock speed and core count. Perhaps half, which is impressive for the age of the chip. All these bugs affecting over a decade of CPU design tells us these chips share a lot of the same logic, if not entire blocks unchanged for more than a decade.
Instead, ended up going i7-875K -> i5-3570K -> Ryzen 1600 -> Ryzen 3700X (probably, this year). So like, I'm glad to see AMD back in the game, but Bulldozer was pretty rough.
I mean at the time the only thing on the minds of consumers was those GHz. So the only way to stay in the market was to hunt those GHz even if it meant some long term pain. After hitting the 3GHz/4GHz frequency walls consumers began to realise that processors are distinguished by more than frequency (obviously the lay person still doesn't quite understand but they're more likely to buy based on i7 > i5 than 3Ghz > 2.5Ghz these days).
No, AMD dispelled that long before Bulldozer, and even Intel had abandoned the GHz game years ago with the Core lineup.
You're thinking late 90s, Bulldozer happened in 2011. People got over the GHz mindset in the early-mid 2000s when the market told 'em we're now going to increase core count instead, and before that when Athlon labeled CPUs like 1800+ (it's not 1.8GHz but it's as fast as one!).
https://patents.google.com/patent/US3728692
https://patents.google.com/patent/US3771138
https://scalibq.wordpress.com/2012/02/14/the-myth-of-cmt-clu...
Not sure if SMT parents would fall under that, but it was my impression that AMD was relatively unconstrained wrt Intel patents due to this agreement.
I would say that only the Instruction set is cross licensed, implementation techniques and hardware interfaces aren't (AMD CPUs shall not be compatible with Intel sockets, for example). Intel's SMT is known as hyper-threading, the patent has expired too but the name "hyper-threading" is still copyright protected and the property of Intel.
My understanding is that they don't have the manufacturing capacity to ship this many processors, even if data centre operators wanted to buy them.
That is the current situation as they Fabbed on 14nm with Global Foundry, together with their GPU and APU. So AMD is completing against itself on capacity. Once they moved off GF to TSMC with 7nm Zen 2, things should [1] hopefully be a lot better.
[1] That is assuming the yields are good, and I/O chip's production will not let down by who ever is fabbing it. Current guess it would still be Global Foundry for IO.
I doubt intel could keep up much better.
Right now it looks like they're going to be reset back to 2017 numbers, losing the business gains they made in 2018. Their sales have fallen for the last three quarters in a row, quarter over quarter, and they barely turned a profit last quarter. Sales imploded by 23% last quarter year over year. When does the amazing year start?
2019 is going to be an absolutely phenomenal year for AMD.
I'm happy to hear that AMD does better with this. I'd already decided that I won't be buying Intel CPUs anymore, so I like that AMD is a reasonable replacement.
Optane used to be very attractive when it promised all the performance at cheaper than DRAM price. But now DRAM price has sunk, and we will have to see whether 2nd gen Optane will deliver what Intel promised.
Or, instead of detecting various things and flushing out sensitive data on some context switch, the CPU just adds noise to the timers instead? I'm gussing this is a complete no-go, but I'm wondering why it is?
For a simple example, imagine you want to distinguish a 1ms difference in the execution time of some operation. Without noise, you just have to time it; now let's randomly add either nothing or 1ms to the operation time, so the "fast" operation will take either +0ms or +1ms, and the "slow" operation will take either +1ms or +2ms. But if you repeat the same operation several times and average the execution times, the "fast" operation will take an average of +0.5ms, and the "slow" operation will take an average of +1.5ms. As you can see, in this simple example the random noise averaged itself to a normal distribution, and the original signal is still visible on top of it.
Meaning to matter how many samples you take, the mean (of the samples) is just as variable as an individual sample.
The mean and variance of the distribution (equivalently, of infinite samples) are undefined. The Cauchy is equivalent to a t distribution with 1 degree of freedom.
Infinite variability will be undesirable for lots of reasons though.
When you talk about timers and resolution, what do you actually mean? When I hear timer, I think about setTimeout, when I hear resolution, I'm thinking about screen resolutions.
Is that what you mean, or are you referring to other things?
Resolution is the precision that the timer reports the time. For example, it could report seconds elapsed (e.g: 8 seconds), it could report milliseconds (8.432 seconds), it could report microseconds (8.432389 seconds), etc.
Attackers want high resolution timers so that they can distinguish cache hits from misses (8.432389 seconds vs 8.432367 seconds, for example).
You'd have to run an old kernel to really get pre-mitigation performance. I tested this just after Meltdown + Spectre 1-3, so things may have better or worse since then, I'm not sure.
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 3 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f[1]: https://support.microsoft.com/en-us/help/4072698/windows-ser...
Having seen the attempts at making Linux friendly for theoretical frictionless spherical Joes in vacuum, I'd rather just have my 1-2% market share GNU/Linux OS for unix greybeards, warts and all. The friendly GUI shell on top of Linux for average Joes is called Chrome OS and Android.
Many people bought the 8700k for a level of performance, that they now need to compromise for: 1) higher performance, small chance of exploits, 2) lower performance and less exploits.
This dilemma did not exist until this year, and now everyone is paying for it, besides Intel.
I doubt it. The cost of workarounds is probably far worse than the time saved from using unsafe methods.
I wouldn't do this at a data center or a nuclear powerplant, but for personal workloads like gaming this might be an okay tradeoff.
This is an argument that anti-vaxxers use. And it works -- until enough people do it to compromise herd immunity. Then, suddenly, it doesn't work and you have a Very Bad Time.
(I don't want to claim that any of the reasoning here is true, but I just wanted to point out the parallel to what you're saying.)
See: https://v8.dev/blog/spectre
> we quickly discovered that software mitigation of all possible leaks due to Spectre was infeasible.
Are there many other security issues that are easier to exploit with potentially higher impact? Sure. Does this mean that Spectre is fixed or can be mitigated in software? No. It's a bit like the formerly theoretical timing attacks against TLS: attacks only get better.
However this conversation might be meaningless, as it seems we have a different definition of what constitutes a feasible attack.
I still maintain my opinion that not turning on mitigations is safe for personal computing.
https://slideplayer.com/slide/12035043/69/images/28/Reaction...
Google clearly considered it an important enough issue to spend considerable resources on trying to mitigate Spectre and in the end only gave up because they didn't find a feasible way to do so. They emphatically didn't conclude that it's fine because attacks are impractical.
This attitude was learned the hard way though: about a decade ago the PoC or gtfo attitude was prevalent among browser makers and large tech companies. Theoretical vulnerabilities were dismissed if no immediate proof of concept was provided.
What changed this was a bunch of security/cryptographical vulnerabilities. MD5 was known to be theoretically week for years and years, but when researchers minted their "can break every SSL/TLS connection" intermediate certificate to finally make browser vendors move on the issue, it was too late.
You see with systemic issues, in cryptography or hardware, by the time you actually demonstrate a PoC, things are way too late: it takes years if not half a decade (as in MD5's case, or with older TLS versions) to deprecate insecure things, if you look at the timelines.
So for issues in fundamental building blocks, it's more or less irrelevant if there is a working PoC today or not: if we don't move to fix the underlying issue and start acting on a roadmap to move away from insecure things, people _will_ come up with a working exploit that allows practical attacks. If mitigation is only attempted at that point then we're being left vulnerable for years to come.
By that logic, all current crypto is already broken and we should only use quantum safe crypto.
You guys threat model for your personal computers are way beyond most of the planet, so I will concede and agree that you should not use browsers or run untrusted code until new CPU's are released. That is pretty much the only thing that will match your threat model.
This should help increase performance again, right? I'm actually waiting for Ice Lake before buying a new laptop.
[1] https://www.tomshardware.com/news/intel-9th-generation-coffe... [2] https://en.wikipedia.org/wiki/Ice_Lake_(microarchitecture)
I wonder, as cores continue to increase, if another solution will present itself in the form of segregating traffic per processor.
It isn't hard to imagine a future where multithreaded applications with write disabled executable memory would be faster to the point where browsers will stop using JIT as we know it.
Memory encryption might work as a way to solve that, but we already know how to solve that -- do what AMD and others have been doing the whole time and don't continue speculative execution through a page fault.
The mantra is, secrecy is not security. The User/Kernel dichotomy flagrantly ignores this principle.
15% vs. 3% is pretty meaningful. 15-16% is comparable to the gap between 4th and 9th generation Intel processors at the same frequency. And in that time turbo has gotten better but base clocks have dropped.
It's unlikely to be lower than 40% unless you're bottlenecked before the CPU (memory speed or heavy CPU cache invalidation)
"Disabling [hyperthreading] increases the overall performance impact to 20 percent (for the 7980XE), 24.8 percent (8700K) and 20.5 percent (6800K)."
...so I think a performance impact of "20%+" (i.e. 20% or more) is fair - for the 8700K it's 24.8%.
Intel being five times more careless and/or incompetent and/or malicious has implications beyond practical performance degradation.