Hacker News Reader

Comment by mtgx | Hacker News Reader

Are they doing any kind of translation, too, or just pure emulation? Because if they aren't, then Windows will continue to run significantly slower on the already significantly lower-performance third-party Arm chips compared to how macOS runs on the M1.

My prediction is 50%-60% of the performance of M1 on the latest/highest-end Qualcomm laptop chip.

View on HN

Some of the perf gains on the M1 are due to hardware support for TSO (total store ordering), which doesn't exist on the latest/highest-end Qualcomm chip, hence the Windows support needs to insert many more barriers to emulate TSO. This likely has a significant impact on emulated performance.

At least the x86 (32-bit) emulation relied entirely on JIT compiling its emulated code, instead of doing anything AOT. _However_, it cached the JIT'd code so in practice it was a first-run cost, similar to the situation on macOS.

I believe windows elides TSO guarantees when it thinks they aren't necessary. This should usually work out all right–only a small amount of code usually cares very much about memory ordering.

That seems like a very difficult task to determine when it matters.

The post says "x64 emulation for ARM64 devices" for applications. Windows itself is already native on ARM64. And some apps too: Edge, Photoshop.

https://blogs.windows.com/windows-insider/2020/12/10/introdu...

I think the parent comment was worded poorly but this is how I'd look at it.

MacOS with M1 runs software compiled for ARM at 100%.

MacOS with M1 runs translated software via Rosetta 2 at like 95%.

Windows on ARM runs software compiled for ARM at 100%.

Windows on ARM runs x86/x64 emulation at 60%.

If Windows for ARM would replace x86/x64 emulation with binary translation, they might remove a significant barrier to ARM adoption (on Windows) by removing the harsh penalty of having to emulate legacy software until enough native/compiled for ARM software exists.

Reply on news.ycombinator.com