It&#x27;s definitely surprising that Qualcomm didn&#x27;t. Not only does Windows have a longer tail of software to support, but given that the vast majority of Windows machines will continue to be x86-64, there&#x27;s little incentive to do work to support ARM.With the Mac, Apple told everyone &quot;we&#x27;re moving to ARM and that&#x27;s final.&quot; With Windows, Microsoft is saying, &quot;these ARM chips could be cool, what do you think?&quot; On the Mac, you either got on board or were left behind. Users knew that the future was ARM and bought machines even if there might be some short-term growing pains. Developers knew that the future was ARM and worked hard to support it.But with Windows, there isn&#x27;t a huge incentive for users to switch to ARM and there isn&#x27;t an incentive for developers to encourage it. You can say there&#x27;s some incentive if the ARM chips are better. While Qualcomm&#x27;s chips are good, the benchmarks aren&#x27;t really ahead of Intel&#x2F;AMD and they aren&#x27;t the power-sipping processors that Apple is putting out.If Apple hadn&#x27;t implemented TSO, Mac users&#x2F;developers would still switch because Apple told them to. Qualcomm has to convince users that their chips are worth the short-term pain - and that users shouldn&#x27;t wait a few years to make the switch when the ecosystem is more mature. That&#x27;s a much bigger hill to climb.Still, for Qualcomm, they might not even care about losing a little money for 5-10 years if it means they become one of the largest desktop processor vendors for the following 20+ years. As long as they can keep Microsoft&#x27;s interest in ARM as a platform, they can bide their time.

Qualcomm has been phoning it in in various forms for over a decade, including forcing MS to ship machines that do not really pass windows requirements (like broken firmware support). Maybe it got fixed with recent Snapdragon X, but I won&#x27;t hold my breath.We&#x27;re talking about a company that, if certain personal sources are to be believed, started the Snapdragon brand by deciding to cheapen out on memory bandwidth despite feedback that increasing it was critical and leaving the client to find out too late in the integration stage.Deciding that they make better money by not spending on implementing TSO, or not spending transistors on bigger caches, and getting more volume at lower cost, is perfectly normal.

Microsoft&#x27;s AoT+JiT techniques still pull off impressive performance (90+% in almost every case, 96-99% in the majority).But yes, if they were actually serious about Windows on ARM, they would have implemented TSO in their &quot;custom&quot; Qualcomm SQ1&#x2F;SQ2 chips.

&gt; Qualcomm didn&#x27;t implement TSO in the chips they madeI’m not sure they can do that.Under Technology License Agreement, Qualcomm can build chips using ARM-designed CPU cores. Specifically, Qualcomm SQ1 uses ARM Cortex A76&#x2F;A55 for the fast&#x2F;slow CPU cores.I don’t think using ARM designed cores is enough to implement TSO, need custom ARM cores instead of the stock ones. To design custom ARM cores, Qualcomm needs architecture license from ARM which was recently been cancelled.

My guess is that the sort of &quot;legacy x86-forever&quot; apps for Windows don&#x27;t really need much in the way of performance. Think your classic Visual Basic 6 sort of thing that a business relies on for decades.I&#x27;m also fairly certain that the TSO changes to the memory system are non-trivial, and it&#x27;s possible that Qualcomm doesn&#x27;t see it as a value-add in their chips - and they&#x27;re probably right. Windows machines are such a hot mess that outside a relatively small group of users (who probably run Linux anyway, so aren&#x27;t anyone&#x27;s target market), nobody would know or care what TSO is. If it add costs and power and doesn&#x27;t matter, why bother?

On a first order analysis, Qualcomm doesn&#x27;t want good x64 support, because good x64 support furthers the lifetime of x64, and delays the &quot;transition&quot; to ARM. In the final analysis, I doubt that is an economically rational strategy, because even if there is to be a transition away from x64, you need a good legacy and migration story. And I doubt such a transition will happen in the next 10 years, and certainly not spurred by anything in Microsoft land.So maybe it&#x27;s rational after all, because they know these Windows ARM products will never succeed, so they&#x27;re just saving themselves the cost&#x2F;effort of good support.

Does Windows&#x27;s translation take advantage of those where they exist? E.g. if I launch an aarch64 Windows VM on my M2, does it use the M2&#x27;s support for TSO when running x86_64 .exes or does it insert these memory barriers?If not, it makes sense that Qualcomm didn&#x27;t bother adding them.

You can use RCpc atomics which are part of the standard architecture

It&#x27;s surprising that (AFAIK) Qualcomm didn&#x27;t implement TSO in the chips they made for the recent-ish Windows ARM machines. If anything they need fast x86 emulation even more than Apple does since Windows has a much longer tail of software support than macOS, there&#x27;s going to be important Windows apps that stubbornly refuse to support native ARM basically forever.

TSO is nice to have but it&#x27;s definitely not necessary. Rosetta doesn&#x27;t even require TSO on Linux anymore by default. It performs fine for typical applications.

Barrier injection isn&#x27;t the issue as much as the barriers becoming expensive. There&#x27;s no reason a CPU can&#x27;t use the techniques of TSO support to support lesser barriers just as cheaply.

I get pretty close to native performance with Rosetta 2 for Linux and I don&#x27;t believe TSO is being used or taken advantage of. I wonder how important it really is.

TSO is what x86 do when you are _not_ using atomics.

Is TSO something other than doing atomics with seq_cst?

perhaps you could keep each process on one core. But that would kill multi-threaded performance.

Post got the big one: Total Store Ordering (TSO).The rest are all techniques in reasonably common use, but unless you have hardware support for x86&#x27;s strong memory ordering, you cannot get very good x86-on-ARM performance, because it&#x27;s by no means clear when strong memory ordering matters, and when it doesn&#x27;t, inspecting existing code - so you have to liberally sprinkle memory barriers around, which really kill performance.The huge and fast L1I&#x2F;L1D cache doesn&#x27;t hurt things either... emulation tends cache-intensive.

I think it is less of numbers game and more of a guarantee thing. As a user of a new Apple silicon machine you do not have to worry about running x86 software. (Aside from maybe specific audio software and such that are a pain to run on any other hardware and software combination.)As such it may very well be a loss leader and that is fine. Probably most development has been done and there is little maintenance needed.Also, while most native macOS apps that I encounter have an Apple silicon version now, I still find docker images for amd64 without an arm64 version present. Rosetta2 also helps with these applications.

&quot;Apple M-series chips emulating x86,&quot; in certain benchmarks and behaviors, was right up there with the fastest x86 chips at the time - I&#x27;d guess largely in stuff that benefited from the huge L1I&#x2F;L1D cache (compared to x86).I had a M1 Mini for a while, and it played Kerbal Space Program (x86) far better than my previous Intel Mini, which had Intel Integrated Graphics that could barely manage a 4k monitor, much less actual gaming.I believe there&#x27;s a way to use Rosetta with Linux VMs, too (to translate x86 VM applications to ARM and run them natively) - but I no longer have any Macs, so I&#x27;ve not had a chance to play with it.

The more important question is how many people buy a MacBook because they know they can run an x86 app if they have to.Just because 0.1% of apps need a feature, the lack of it won&#x27;t translate into only 0.1% of lost sales. People don&#x27;t behave like that.So the more important question is: how many people moved to ARM because they felt they don&#x27;t need to worry about compatibility with existing use cases?

Then again games didn&#x27;t stop Apple from dropping x86-32 support, which nuked half of the Mac Steam library. It wouldn&#x27;t be out of character for them to drop x86-64 support and nuke the rest which haven&#x27;t been updated to native ARM.

VSTs. Just as people use vintage physical synthesizers, old guitars, and recording equipment, people use old software that might not ever be updated.

Games. So many games.Also, x86 containers.

There can&#x27;t be that many other people using it, but I&#x27;m using Rosetta2 to run the SML&#x2F;NJ (<a href="https:&#x2F;&#x2F;www.smlnj.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.smlnj.org&#x2F;</a>) implementation of Standard ML. The development team is working on a macOS&#x2F;ARM64 backend, though.

Does Apple ecosystem have any production software any enterprise or industry uses? I recall maintaining Windows Server 2000 related production software just last week. Working software can be really, really old

Super interesting.
Putting my PM hat on, I wonder: how many x86 apps on Apple still benefit from this much performance? What&#x27;s the coverage? The switch to M1 happened 4 years ago, so the software was designed for hardware nearly half a decade old.Excellent engineering and nice that it was built properly. Is this something that Linux &#x2F; Wine &#x2F; the Steam compatibility layer already benefit from?

Standardization of future Arm PCs, <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42182442">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42182442</a><pre><code> The Arm PC Base System Architecture 1.0 (PC-BSA) specifies a standard hardware system architecture for Personal Computers (PCs) that are based on the Arm 64-bit Architecture. PC system software, for example operating systems, hypervisors, and firmware can rely on this standard system architecture. PC-BSA extends the requirements specified in the Arm BSA.</code></pre>

I confess I don&#x27;t really know the technical details of how they use Rosetta, but according to their docs [1]:&quot;We use Rosetta to emulate x86 programs on Apple Silicon, which is much faster than the commonly-used QEMU.&quot;What I get is that rosetta is used when you run something on Docker that uses x86 architecture (I&#x27;m guessing x86_64), which for me is pretty often.--1: <a href="https:&#x2F;&#x2F;docs.orbstack.dev&#x2F;architecture#low-level-vm-optimizations" rel="nofollow">https:&#x2F;&#x2F;docs.orbstack.dev&#x2F;architecture#low-level-vm-optimiza...</a>

OrbStack doesn&#x27;t use Rosetta 2. It does support Rosetta 2 for Linux, but it&#x27;s something you would have to go out of your way to use.

Tangent: also why orbstack, a Docker replacement on Mac, is fast [1] (I&#x27;m not affiliated in any way, just a fan and happy user :-).--1: <a href="https:&#x2F;&#x2F;docs.orbstack.dev&#x2F;features" rel="nofollow">https:&#x2F;&#x2F;docs.orbstack.dev&#x2F;features</a>

I wonder if these lessons might be applied to Wasm runtimes where the Wasm could be JIT compiled into native code. Of course this does raise the possibility of security concerns if the Wasm compilation has some bug, and then of course there’s also the question of whether Wasm’s requirements might mean native compilation doesn’t give much of a performance boost (as seems to be the case with e.g., Java byte code).

One other thing that is not mentioned is that Apple has an extension to compute rarely used x86 flags such as the parity flag in hardware rather than in software.

Why is Apple Rosetta 2 fast? (2022)