I think it's important to call out that Rosetta 2 on Apple silicon uses a special mode that changes how the memory model works to support x86 style memory ordering. That massively reduces the amount of work needed to emulate x86 and x86-64. Pretty sure apple both has a patent on it and a special dispensation from ARM to use it. Where qualcomm and MS don't have either. Which means emulation on Qualcomm CPUs is going to be painfully slow in comparison because it has to use a lot more locks and fences than is actually necessary with that mode available.
> I think it's important to call out that Rosetta 2 on Apple silicon uses a special mode that changes how the memory model works to support x86 style memory ordering. That massively reduces the amount of work needed to emulate x86 and x86-64. Pretty sure apple both has a patent on it and a special dispensation from ARM to use it.
>Myth: Apple chips are the only ones to implement the x86 TSO memory model.
Interesting, this is news to me. More curious that A64fx has it since that's an HPC chip. They must have a very valid reason for it (I've definitely run into HPC code that is absolutely garbage and would need it to be stable).
The biggest reason for Windows' dominance for the better part of almost two decades was its insane backwards compatibility. Of course, this also created a myriad of problems for bloat and security, but it was pretty much one of their biggest selling points.
It's gotta be just as good as Apple's, or nobody's going to care, point-blank. They'll just buy a Mac and put Windows in a VM. You might even get better performance.
> And in an embarrassing turn of events, right now at least, you can eke out more performance running x86 code inside Apple's Rosetta 2 in a Linux VM under Windows than you can using Windows' native emulation layer!
So clearly there's more going on than just leveraging TSO support on Apple's chips.
Isn't that an unfair comparison? I would think that Rosetta 2 relies on TSO being enabled, so if you use it on a processor that doesn't actually implement TSO it's probably wildly unsafe while a more correct/safe emulator has to incur extra overhead to work around the lack of TSO.
The Verge review of the Surface Pro 9 did mention that x86 software is not just laggy, but also crashes.
>My frustration with this computer wasn’t a workload thing. It didn’t start out fast and gradually slow down as I opened more things and started more processes. It was peppered with glitches and freezes from start to finish.
I’d have only Slack open, and switching between channels would still take almost three seconds (yes, I timed it on my phone). Spotify, also with nothing in the background, would take 11 seconds to open, then be frozen for another four seconds before I could finally press play. When I typed in Chrome, I often saw significant lag, which led to all kinds of typos (because my words weren’t coming out until well after I’d written them). I’d try to watch YouTube videos, and the video would freeze while the audio continued. I’d use the Surface Pen to annotate a PDF, and my strokes would either be frustratingly late or not show up at all. I’d try to open Lightroom, and it would freeze multiple times and then crash.
If the allegation that MS is locked to Qualcomm is true and the support of TSO as mentioned in other comments does not include any offering from the same my guess is MS hasn't bothered. They may yet if Qualcomm implements it.
