> We’ve known for decades that RISC was the “right” design, but x86 was so far ahead of everyone else that switching architectures was completely infeasible
All the experts I listened or read to, they told that instruction set doesn't matter and it is the insignificant thing. The part that matters is branch and data prediction, and caching. Also, even intel transforms an instruction into RISC like microinstructions internally.
> Apple does not have to worry about backwards compatibility very much compared to a Windows-based manufacturer
Windows is literal shit in backwards compatibility too. Try to run any windows 7 or before program in windows 10 and most of the time it won't work. Also, windows can also run in ARM and unlike mac the ARM windows didn't had emulation for years.
> All the experts I listened or read to, they told that instruction set doesn't matter and it is the insignificant thing. The part that matters is branch and data prediction, and caching. Also, even intel transforms an instruction into RISC like microinstructions internally.
That's commonly repeated, but is a misunderstanding. Up until this point the difference was mostly that an x86 decoder took up more chip area, which given Intel's historical leads in process tech was no big deal to them.
However now we're pushing chips to go wider than ever. Intel and AMD haven't been able to push past a 4x superscalar decoder. The instruction set just has too many potential chained dependencies to make it work. You'd have to slow cycle time or introduce additional pipeline stages such that performance in the net is worse. Meanwhile M1 decodes at 8x.
This dovetails into what you're saying about stalls caused by prediction and caching. Once the stall is resolved M1 can race ahead, assigning work into the shadow registers at potentially twice the peak rate.
You're being a bit hyperbolic about Windows backwards compatibility. Much of the enterprise software world is still running programs that were written against windows XP just fine, and MS is not going to rock that boat any time soon.
The big difference with Apple's transition is precisely due to the translation (note not emulation). I've lived through 3 of their ISA changes now and they've all been nearly seamless. The big difference is Mac users have been ok with sunsetting the old apps ~5 years after the transition, something that's a total nonstarter in Windows land.
Rosetta2 is so stinking fast I have not even had to think one whip about what's native vs translated.
"That's commonly repeated, but is a misunderstanding. Up until this point the difference was mostly that an x86 decoder took up more chip area, which given Intel's historical leads in process tech was no big deal to them.
However now we're pushing chips to go wider than ever. Intel and AMD haven't been able to push past a 4x superscalar decoder. The instruction set just has too many potential chained dependencies to make it work. You'd have to slow cycle time or introduce additional pipeline stages such that performance in the net is worse. Meanwhile M1 decodes at 8x."
Thank you, for the love of Christ why people regurgitate this [half-truth about the decoders] consciously without realizing what they are implying is beyond me. Sure, in a world where Apple, ARM. et. al were slow, maybe it would be a relevant defense. But they're playing ball, and MS/Intel haven't been up to bat with it the home turf truly on the line for years. Likely Intel will shift over to fabs for third-parties, MS is fine without Windows were it to fade out to Chrome/MacOS in time (unlikey but still).
I think there's another variable on MS's end too. Paging. The M1 supports 16K paging/allocation unit sizes, right? I strongly suspect this + the ssd speed & memory compression plays a substantial role in the reported "differential use of ram" which probably also explains the swap rates that everyone keeps coping about (obviously, they are built this way for the most part). On performance though, I don't really put much stock in EclecticLightCo's thing on QoS, at least, not any stock in it as though I genuinely subscribe to the school of thought praising Apple for perfecting heterogeneous core scheduling, which is really just a bit much.
And yeah, I went from 2020 x86 MBP to 2020 M1 MBA. Seamless, and I really haven't thought about emulation other than for instance the apparent memory usage that may be a bit more accentuated with Rosetta.
> All the experts I listened or read to, they told that instruction set doesn't matter and it is the insignificant thing. The part that matters is branch and data prediction, and caching. Also, even intel transforms an instruction into RISC like microinstructions internally.
I've heard this before, but I've also seen sources which indicate that x86 instruction decoding is definitely a bottleneck [1-5]. The M1 has a significantly wider pipeline/OoO window/reorder buffer than any other processor, and most sources seem to agree that this is because the simplicity of the ARM ISA allowed Apple to build an 8-wide instruction decoder (as compared to around 4-wide for x86 chips). [1] also mentions that Apple's impressive branch-prediction capabilities are at least partially because ARM's 4-byte-aligned instructions greatly simplify the design of the branch predictor.
So yes, it's true that an x86 processor really runs RISC-like uops under the hood. However, the best out-of-order execution pipeline in the world is limited by how far ahead it can see, and that depends on how fast the instruction decoder can feed it instructions.
Once again though, I am not a microarchitecture expert. I just read bits of information from people who do know what they're talking about and try to form it into a coherent mental model. If you have knowledge or sources that disagree with me, I would be happy to be proven wrong :)
All the experts I listened or read to, they told that instruction set doesn't matter and it is the insignificant thing. The part that matters is branch and data prediction, and caching. Also, even intel transforms an instruction into RISC like microinstructions internally.
> Apple does not have to worry about backwards compatibility very much compared to a Windows-based manufacturer
Windows is literal shit in backwards compatibility too. Try to run any windows 7 or before program in windows 10 and most of the time it won't work. Also, windows can also run in ARM and unlike mac the ARM windows didn't had emulation for years.