3 ms·

Does anybody know if the X2 supports the x86 Total store ordering (TSO) memory ordering model? That's how Apple silicon does such efficient emulation of x86.

Does anybody know if the X2 supports the x86 Total store ordering (TSO) memory ordering model? That's how Apple silicon does such efficient emulation of x86. I'd think that would be even MORE important for a Windows ARM64 laptop where there is so much more legacy x86 software going back decades.

londons_explore 1y ago
For really old software, it tends not to make good use of multiple cores anyway and you can simply emulate just a single core to achieve total store ordering. Anything modern and popular and you can probably get it recompiled to ARM64
- 0x000xca0xfe 1y ago
  Unfortunately games are the most common demanding multithread applications. Studios throw a binary over the fence and then get dissolved. Seems to be the way the entire industry operates. Maybe more ISA diversity will incentivize publishers to improve long-term software support but I have little hope.
bri3d 1y ago
Does anyone have benchmarks for Rosetta with TSO vs the Linux version with no-TSO? I guess it might be a bit challenging to achieve apples to apples, although you could run a test benchmark on OSX and then Asahi on the same hardware, I think? I've always been curious about just how much Rosetta magic is the implementation and how much is TSO; Prism in Windows 24H2 is also no slouch. If the recompiler is decent at tracing data dependencies it might not have to fence that much on a lot of workloads even without hardware TSO.
- ack_complete 1y ago
  People who have worked on the Windows x64 emulator claim that TSO isn't as much of a deal as claimed, other factors like enhanced hardware flag conversion support and function call optimizations play a significant role too: http://www.emulators.com/docs/abc_exit_xta.htm http://www.emulators.com/docs/abc_exit_xta.htm
  - bri3d 1y ago
    This is more like what I’d expect! This is a great article too, thank you, this is the kind of thing I come to HN for :)
  - neobrain 1y ago
    > People who have worked on the Windows x64 emulator claim that TSO isn't as much of a deal as claimed This is a misinterpretation of what the author wrote! There is a real and significant performance impact in emulating x86 TSO semantics on non-TSO hardware. What the author argues is that enabling TSO process-wide (like macOS does with Rosetta) resolves this impact but it carries counteracting overhead in non-emulated code (such as the emulator itself or in ARM64EC). The claimed conclusion is that it's better to optimize TSO emulation itself rather than bruteforce it on the hardware level. The way Microsoft achieved this is by having their compiler generate metadata about code that requires TSO and by using ARM64EC, which forwards any API calls to x86 system libraries to native ARM64 builds of the same libraries. Note how the latter in particular will shift the balance in favor of software-based TSO emulation since a hardware-based feature would slow down the native system libraries. Without ecosystem control, this isn't feasible to implement in other x86 emulators. We have a library forwarding feature in FEX, but adding libraries is much more involved (and hence currently limited to OpenGL and Vulkan). We're also working on detecting code that needs TSO using heuristics, but even that will only ever get us so far. FEX is mainly used for gaming though, where we have a ton of x86 code that may require TSO (e.g. mono/Unity) but wouldn't be handled by ARM64EC, so the balance may be in favor of hardware TSO either way here. For reference, this is the paragraph (I think) you were referring to: > Another common misconception about Rosetta is that it is fast because the hardware enforces Intel memory ordering, something called Total Store Ordering. I will make the argument that TSO is the last thing you want, since I know from experience the emulator has to access its own private memory and none of those memory accesses needs to be ordered. In my opinion, TSO is ar red herring that isn't really improving performance, but it sounds nice on paper.
    - ack_complete 1y ago
      How is it a misinterpretation? To re-quote that last sentence: > In my opinion, TSO is a red herring that isn't really improving performance, but it sounds nice on paper. That's the author directly saying that TSO isn't the major emulation performance gain that people think it is. You're correct that there are countering effects between TSO's benefits to the emulated code vs. the negative effects on the emulator and other non-emulated code in the same process that are fine running non-TSO, but to users, this distinction doesn't matter. All that matters is the performance of emulated program as a whole. As for the volatile metadata, you're correct that MSVC inserts additional data to aid the emulation. What's not so great is that: - It was basically an almost undocumented, silent addition to MSVC. - In some cases, it will slow down the generated x64 code slightly by adding NOPs where necessary to disambiguate the volatile access metadata. - It only affects code statically compiled with a recent version of MSVC (late VS2019 or later). It doesn't help executables compiled with non-MSVC compilers like Clang, nor any JIT code, nor is there any documentation indicating how to support either of these cases.
- justincormack 1y ago
  There was a paper with benchmarks posted recently here but I cant find it immediately. I think it was 6-10% from memory.
- throawayonthe 1y ago
  i mean, FEX runs on a linux host both with and without TSO, can be compared directly (the downstream asahi kernel supports TSO)

londons_explore 1y ago

For really old software, it tends not to make good use of multiple cores anyway and you can simply emulate just a single core to achieve total store ordering. Anything modern and popular and you can probably get it recompiled to ARM64

0x000xca0xfe 1y ago
Unfortunately games are the most common demanding multithread applications. Studios throw a binary over the fence and then get dissolved. Seems to be the way the entire industry operates. Maybe more ISA diversity will incentivize publishers to improve long-term software support but I have little hope.

bri3d 1y ago

Does anyone have benchmarks for Rosetta with TSO vs the Linux version with no-TSO? I guess it might be a bit challenging to achieve apples to apples, although you could run a test benchmark on OSX and then Asahi on the same hardware, I think? I've always been curious about just how much Rosetta magic is the implementation and how much is TSO; Prism in Windows 24H2 is also no slouch. If the recompiler is decent at tracing data dependencies it might not have to fence that much on a lot of workloads even without hardware TSO.

ack_complete 1y ago
People who have worked on the Windows x64 emulator claim that TSO isn't as much of a deal as claimed, other factors like enhanced hardware flag conversion support and function call optimizations play a significant role too: http://www.emulators.com/docs/abc_exit_xta.htm http://www.emulators.com/docs/abc_exit_xta.htm
- bri3d 1y ago
  This is more like what I’d expect! This is a great article too, thank you, this is the kind of thing I come to HN for :)
- neobrain 1y ago
  > People who have worked on the Windows x64 emulator claim that TSO isn't as much of a deal as claimed This is a misinterpretation of what the author wrote! There is a real and significant performance impact in emulating x86 TSO semantics on non-TSO hardware. What the author argues is that enabling TSO process-wide (like macOS does with Rosetta) resolves this impact but it carries counteracting overhead in non-emulated code (such as the emulator itself or in ARM64EC). The claimed conclusion is that it's better to optimize TSO emulation itself rather than bruteforce it on the hardware level. The way Microsoft achieved this is by having their compiler generate metadata about code that requires TSO and by using ARM64EC, which forwards any API calls to x86 system libraries to native ARM64 builds of the same libraries. Note how the latter in particular will shift the balance in favor of software-based TSO emulation since a hardware-based feature would slow down the native system libraries. Without ecosystem control, this isn't feasible to implement in other x86 emulators. We have a library forwarding feature in FEX, but adding libraries is much more involved (and hence currently limited to OpenGL and Vulkan). We're also working on detecting code that needs TSO using heuristics, but even that will only ever get us so far. FEX is mainly used for gaming though, where we have a ton of x86 code that may require TSO (e.g. mono/Unity) but wouldn't be handled by ARM64EC, so the balance may be in favor of hardware TSO either way here. For reference, this is the paragraph (I think) you were referring to: > Another common misconception about Rosetta is that it is fast because the hardware enforces Intel memory ordering, something called Total Store Ordering. I will make the argument that TSO is the last thing you want, since I know from experience the emulator has to access its own private memory and none of those memory accesses needs to be ordered. In my opinion, TSO is ar red herring that isn't really improving performance, but it sounds nice on paper.
  - ack_complete 1y ago
    How is it a misinterpretation? To re-quote that last sentence: > In my opinion, TSO is a red herring that isn't really improving performance, but it sounds nice on paper. That's the author directly saying that TSO isn't the major emulation performance gain that people think it is. You're correct that there are countering effects between TSO's benefits to the emulated code vs. the negative effects on the emulator and other non-emulated code in the same process that are fine running non-TSO, but to users, this distinction doesn't matter. All that matters is the performance of emulated program as a whole. As for the volatile metadata, you're correct that MSVC inserts additional data to aid the emulation. What's not so great is that: - It was basically an almost undocumented, silent addition to MSVC. - In some cases, it will slow down the generated x64 code slightly by adding NOPs where necessary to disambiguate the volatile access metadata. - It only affects code statically compiled with a recent version of MSVC (late VS2019 or later). It doesn't help executables compiled with non-MSVC compilers like Clang, nor any JIT code, nor is there any documentation indicating how to support either of these cases.
justincormack 1y ago
There was a paper with benchmarks posted recently here but I cant find it immediately. I think it was 6-10% from memory.
throawayonthe 1y ago
i mean, FEX runs on a linux host both with and without TSO, can be compared directly (the downstream asahi kernel supports TSO)