It's not about brand affiliation, AMD and Intel have vastly different implementations
We heard the very same argument about Microsoft Windows back in the 90s and 00s. "Linux [1] just wasn't well tested." It is purely a hypothesis, without any proof whatsoever.
Microsoft lost its dominance. Intel not yet, but this could lead to that. The question with losing dominance (e.g. being monopolist or market leader) is always a question of when, not if. And if it happens some people will lose a lot of money [2]. There's going to be a time where the USA is no longer #1 world power. The question isn't if, it is when. History teaches us this much.
[1] (Whatever that means.)
[2] (Or "money".)
Fast-forward to end of 10s and the dominant client is the web browser stack where Microsoft is barely relevant. That Microsoft Windows and Microsoft Office are still dominant is hardly important as the market trend is that these markets themselves are less relevant. If not merely for the fact that venfor lock-in has shifted, in favor of the other 4 in the FAANG stack.
AMD's server market share is minuscule and dropped as of 19Q1, 3.2% to 2.9%, although healthier and growing smartly in desktops and notebooks, up to 17.1% and 13.1% as of last quarter (I would guess the two are related if the comments made in this discussion about their being fab capacity limited are correct). That means they're less significant targets for researchers than Intel and ARM. We might also assume AMD has less manpower to devote to finding vulnerabilities than Intel has.
These latest Intel vulnerabilities, Foreshadow/L1TF and this week's? They're all targeting Intel specific details, for example the first Foreshadow version targets the SGX enclave. See also ARM's Cortex-A72 Rogue System Register Read (RSRE), Spectre Variant 3a vunerability: https://developer.arm.com/support/arm-security-updates/specu...
The odds that AMD specific features have vulnerabilities than simply haven't been looked for yet is very high, their Spectre vulnerabilities show that they too generally got caught with their pants down.
My understanding from a Google blog that talked about it indicated that Google felt like almost any speculative execution... is a risk. So while there might not be someone exploiting it now, they considered the practice potentially an issue. Accordingly future performance will possibly still degrade later as further changes are possibly needed?
The other vulnerabilities: Meltdown, Fallout, the recent MDS attacks (RIDL, ZombieLoad, Store to Leak forwarding), are Intel specific because they’re caused by the way Intel specifically chose to skip/defer security enforcement checks in parts of their implementation.
Other companies didn’t do this.
ARM, and IBM POWER and mainframe/Z also did that (Meltdown): https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili... ARM also has a Rogue System Register Read vulnerable design (https://developer.arm.com/support/arm-security-updates/specu...).
Every company with high performance single thread designs has out-of-order with speculative execution designs, ARM, AMD, IBM POWER and mainframe/Z, Intel, MIPS, and SPARC. RISC-V is working on it, with the Berkeley Out-of-Order Machine (BOOM) and perhaps other cores.
And doing research I should have done a long time ago, SPARC V9 has Spectre vulnerabilities (https://www.zdnet.com/article/meltdown-spectre-oracles-criti...), and MIPS made a statement that a couple of their designs were possibly vulnerable (https://www.mips.com/blog/mips-response-on-speculative-execu... and this followup assumes that: https://www.mips.com/forums/topic/mips-mitigations-for-side-...)
Also, something everyone seems to forget: All of these cloud providers are running Skylake chips, which were launched in 2015. Google Cloud in particular will even give you chips OLDER than Skylake by default if you don't specifically request Skylake. Even assuming instances like an AWS m5a are running on Zen 1, not Zen 2, that's a 2017 architecture.
So you're presented with all these graphs that say "AMD only lost 5%, Intel lost 25%, fuck Intel" but the reality is that Intel was previously far faster than AMD, and they're not even fabbing their best designs for the data center. Intel definitely had more vulnerabilities and they WERE hit harder, but its more nuanced than just blindly wondering why more cloud providers aren't making a fleet-wide switch to AMD.
Not so surprising now that we know Intel merely skipped a lot of checks to get there though. I mean a lot of the vulnerabilities impacting Intel only have been the likes of "when predicting, the processor does it even it shouldn't to avoid the delay from checking".
Is it really fair then to say that AMD doing it the proper way was slower, or that the loss of performance of Intel can't be used as a way to congratulate AMD on being safer on that front ?
That's a technically true but also misleading statement. It is exclusively on heavy AVX loads that any such delta appears. If you're not using AVX, then the single-thread differences are ~15% or less. So Intel losing 25% does now potentially put them behind on most single-threaded workloads.
1) AMD knew about the potential vulnerabilities that would have emerged by making the CPUs faster "Intel-style" and therefore said something like "no we won't take those risks", or...
2) if it was just by pure luck, or...
3) if for them that option wasn't technically feasible,or...
4) if maybe they did not have as "good" (relatively speaking) engineers as Intel.
Personally I don't think that it could be #1 as I think that the pressure to make the CPU faster (and therefore being able to better compete with Intel) would have been a lot higher than to say "nah, this might hit us in the future so let's opt for the safe variant".
Intel took a gamble and lost. Well, they lost from an honest engineering standpoint. Still unclear if they lost anything from a market perspective, and we may never know because they're losing even bigger in terms of fabrication, which will obscure the effect of their horrible security fumbles.
[1] You don't need to know the details of an exploit to avoid a vulnerability. You just need to know what you don't know, and for side-channel attacks it's relatively easy to know what we don't know--any calculation where a timing, power, etc differential is even indirectly visible (at any level of precision) is suspect. Sometimes you have to take the risk, but some risks (i.e. speculating across security domains) are just too great, especially in an environment as sensitive and security critical as a CPU. Intel engineers knew. They couldn't have not known; they're hardly incompetent.