4 ms·
> Or force Intel and AMD to pull a rabit out of their hat to match the performance/watt of ARM chips I believe I read an article the other day that explained w
by pmarreck 6y ago
> Or force Intel and AMD to pull a rabit out of their hat to match the performance/watt of ARM chips
I believe I read an article the other day that explained why the M1 was so fast and efficient and basically the design it came up with is impossible to do on Intel, for many reasons including the fact that Intel instructions are variable-length (which means they need to be completely parsed every time to find the end of the instruction) while M1 instructions are fixed-length (which means you don't need to parse it) due to the RISC design (finally a winner).
Methinks we are witnessing the death of the traditional Intel chip API as the bad design decisions made along the way come to a head.
Should make things interesting as now both Apple and Linux have a head start on ARM support.
- postalrat 6y agoMicrosoft has a version of windows running on arm in the surface pro. Wouldn't that give them the headstart on apple?
- kzrdude 6y agoApple had versions of iOS running ARM on phones and pads since how many years? They used their head start already to launch themselves into their ARM computers.
- macintux 6y agoAnd it's not particularly relevant, but the Newton was an ARM device, so Apple's head start is even longer than that.
- mattkevan 6y agoARM was a joint project between Apple, Acorn and VLSI, so you could say that they had a head-start on pretty much everyone except Acorn, who invented it in the first place.
- pmarreck 6y agoWhat’s the Windows app compatibility look like on those, though?
- pitterpatter 6y agoMost UWP apps should be easy to compile for ARM. Emulating x86-32 apps on ARM Windows has been a thing for many years and the further expanded x86-64 support is in Insider builds. Really the bigger issue is that the ARM chips Windows has thus far run on don't have the similar TSO opts the M1 came with.
- AstralStorm 6y agoFunny thing, you could make a constant length superset of x86-64 with backwards compatibility, and it's even going to run fast... (The instruction decoder would become more of a translator.) The bigger problem with x86 is the implicit hard synchronization barrier after most writes. This cannot be easily fixed without introducing new instructions altogether.