2 ms·
There's no reason to believe this has to be slower than x86 on ARM
by nly 5y ago
There's no reason to believe this has to be slower than x86 on ARM
- lloeki 5y agoWell, emulating† x86 on ARM is excruciatingly slow, just as emulating ARM on x86 is (turns out I do both, routinely, so no need to believe when I have data: it's about an order of magnitude slower than native) † Rosetta 2 is not emulation.
- saagarjha 5y agoRosetta 2 is an emulator. It has a JIT compiler inside of it!
- smoldesu 5y agoEmulating x86 is slow on ARM because it's inherently a less complex instruction set. Emulating things the other way around is dead-simple by comparison, it's what made it such a cakewalk to write Nintendo Switch emulators on x86. ARM has to swing up the abstraction chain to implement x86 instructions, whereas x86 can execute ARM instructions for cheap, free, or even faster than ARM natively in the case of SIMD calls. Plus, that's ignoring how people will actually try to get MacOS running on these machines. Once x86 is finally considered "dead" and removed from the MacOS ecosystem, the solution is going to be kernel patching. It's hard to speculate on how difficult this might be, but I'd imagine that a small team could port binary patches from BSD to Nu-Mac fairly quickly. It's not a particularly complicated process, just a mite arduous.
- saagarjha 5y agoThis is generally not true. x86 has a bunch of CISCy instructions that translate to several ARM instructions, but ARM also has a bunch of things that encode strangely and split across several x86 instructions. In general, they're not that far apart in complexity. (There are instruction sets where this is true, e.g. older architectures like 6502 or whatever. But it's unlikely to be the case for anything moderately complex.)