Intel shares with Nvidia(also currently using large dies) a limited form of performance leadership at the high end that may be eroded in the face of these shifts. Most of the market is going to see more benefit from more cores instead of faster cores with the current conditions. That might be less true once we're talking about a baseline of 16 or 32 cores, but 2 is proving to be too few for current workloads.
And that's just their nearest competitor. ARM SOCs have consumed the mobile market and are creeping upwards. My ARM Chromebook makes a pretty good Linux desktop too, and you can practically trip over RaspPi devices.
In the end I went with an i7-7700HQ because I simply couldn't make my old laptop last any longer, 8GB ram just wasn't enough for my workflow.
If the mobile Ryzens are amazing I'm going to regret that maybe.
In contrast, the simplicity of RISC means such optimisations are either not possible or much harder --- if by definition all instructions already run in one clock cycle on one execution unit, then the only choices are to add more execution units (something the CISCs can also do with the same amount of difficulty) or attempt to recognise sequences of instructions and combine them for execution on dedicated hardware; the key difficulty here being that recognising and combining instruction sequences is much harder than decoding a single instruction to a sequence of uops or dispatching it to hardware internally.
REP MOVS/STOS is not optimized at all. The Architectures Optimization Reference Manual says that SIMD instructions are faster. The only reasons to use REP MOVS/STOS are to deal with unaligned parts of the data and to not have startup cost from checking if SIMD is available via CPUID when you have only a few bytes. Further the intel manual tells you to not use the other string instructions at all.
> if by definition all instructions already run in one clock cycle
Then you are using a different definition of RISC than RISC-V does
> the key difficulty here being that recognising and combining instruction sequences is much harder than decoding a single instruction to a sequence of uops or dispatching it to hardware internally.
Why is that supposed to be more difficult? Matching combinable instructions is trivial.
That might've been true for a period some time ago, but before and after that it has been the preferred way to do memcpy() or memset() since it can operate on entire cachelines at a time. It's one of the fastest, if not the fastest, and also the absolute smallest (which helps with icache consumption), while leaving the SIMD registers free to do more... useful things than shuffling data around.
https://stackoverflow.com/questions/43343231/enhanced-rep-mo...
https://github.com/golang/go/issues/14630
Why is that supposed to be more difficult? Matching combinable instructions is trivial.
How is it "trivial" to match a round of AES or SHA, or a multiplication or division algorithm, or even a memory copy/store loop, so they can be replaced with the optimal hardware implementation...?
Throw in that we already have a mainstream (if you squint) desktop OS that is a compile away (and has driver support for a lot of hardware) and if I where Intel I'd be worried in the mid-term.
Hell for the first time since the first AMD64's came out Chipzilla is looking vulnerable from the AMD direction, a surprise to a lot of people (including myself, I bought a Ryzen 1700 for work back in late May and I've been astounded by the performance per £ on my workloads).