3 ms·

And arm-windows will (does already?) run x86 binaries with weaker memory ordering than they were written for. So this could be a real thing soon.

by im3w1l 5y ago

belter 5y ago
Now I am worried. Do you have a reference please?
- im3w1l 5y ago
  Best I could find. It's not a great reference because it doesn't give any details but it does prove that it's a thing. https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-program-compat-troubleshooter https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...
kevingadd 5y ago
Are you sure the translators don't insert code necessary to maintain ordering? I would be shocked if most threaded code works when you throw out the x86 memory model. Managed runtimes like .NET definitely generate code for each target designed to maintain the correct memory model.
- pmuderoc 5y ago
  They better do, but then, how would an automatic translator know that this is a "release semantics" atomic store operation? Because on x86 it is, no special barriers or instructions necessary. mov [shared_data], 1 mov [release_flag], 1
  - my123 5y ago
    It’s pessimistic and converts over a lot of memory accesses to RCpc or atomics. (on ARMv8.0 where you don’t have those, barriers are used more) TSO pessimization is the only way to make the thing work at a translation time cost that isn’t too high.
    - gpderetta 5y ago
      Or you support TSO directly on your cpu like Apple does on M1.
      - tsimionescu 5y ago
        Sure, but Windows on ARM has to run on many ARM processors, not a specific one designed by MS. They could detect if the processor has non-standard TSO support and use that when running an x86 app, but they still have to do something to run the x86 app on a standard ARM processor.
- my123 5y ago
  Maintaining the memory model guarantees is what causes the steep cost in performance when using x86 apps on Windows on Arm. That said, heuristics are used to speed it up. I would recommend not sharing values in the stack between threads for synchronisation for example.
- nyanpasu64 5y ago
  https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-program-compat-troubleshooter https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on... > You can also select multi-core settings, as shown here... These settings change the number of memory barriers used to synchronize memory accesses between cores in apps during emulation. Fast is the default mode, but the strict and very strict options will increase the number of barriers. This slows down the app, but reduces the risk of app errors. The single-core option removes all barriers but forces all app threads to run on a single core. https://news.ycombinator.com/item?id=28732273 https://news.ycombinator.com/item?id=28732273 zamadatix's interprets this as Microsoft saying that by default, Windows on ARM runs x86 apps without x86 TSO, and turns on extra memory barriers using per-app compatibility settings. But if an app needs TSO but isn't in Windows's database, it will crash or silently corrupt data.
xxs 5y ago
Normally the code should have all the needed memory fences as if running on DEC Alpha, e.g. linux does that, and the compilers omit the unneeded ones.
- monocasa 5y ago
  And since the compiler omitted it on x86, an x86 emulator doesn't have access to where they're required as seen by the compiler.
  - xxs 5y ago
    emulator would have a zero issue, if it's a direct transfer for assembly (not an emulator), it'd need either hardware support - e.g. apple chips, or memory barriers. The differences between arm and x86 are known for 15y+, there is nothing new about it. Also concurrency support is one of the major benefits of languages with proper memory model - java started it with JMM[0] [0]: https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedL...
    - gpderetta 5y ago
      Any emulator that wants to be remotely performance competitive will do dynamic translation (i.e JIT). In fact ahead-of-time translation is not really feasible. Memory models and JVM are not really relevant when discussing running binaries for a different architecture.
      - secondcoming 5y ago
        Doesn't the JVM define its own memory model?
        gpderetta 5y ago
        Sure, but how's that relevant when discussing running x86 binaries on ARM?

And arm-windows will (does already?) run x86 binaries with weaker memory ordering than they were written for. So this could be a real thing soon.

by im3w1l 5y ago

And arm-windows will (does already?) run x86 binaries with weaker memory ordering than they were written for. So this could be a real thing soon.

belter 5y ago

Now I am worried. Do you have a reference please?

im3w1l 5y ago
Best I could find. It's not a great reference because it doesn't give any details but it does prove that it's a thing. https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-program-compat-troubleshooter https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...

kevingadd 5y ago

Are you sure the translators don't insert code necessary to maintain ordering? I would be shocked if most threaded code works when you throw out the x86 memory model. Managed runtimes like .NET definitely generate code for each target designed to maintain the correct memory model.

pmuderoc 5y ago
They better do, but then, how would an automatic translator know that this is a "release semantics" atomic store operation? Because on x86 it is, no special barriers or instructions necessary. mov [shared_data], 1 mov [release_flag], 1
- my123 5y ago
  It’s pessimistic and converts over a lot of memory accesses to RCpc or atomics. (on ARMv8.0 where you don’t have those, barriers are used more) TSO pessimization is the only way to make the thing work at a translation time cost that isn’t too high.
  - gpderetta 5y ago
    Or you support TSO directly on your cpu like Apple does on M1.
    - tsimionescu 5y ago
      Sure, but Windows on ARM has to run on many ARM processors, not a specific one designed by MS. They could detect if the processor has non-standard TSO support and use that when running an x86 app, but they still have to do something to run the x86 app on a standard ARM processor.
my123 5y ago
Maintaining the memory model guarantees is what causes the steep cost in performance when using x86 apps on Windows on Arm. That said, heuristics are used to speed it up. I would recommend not sharing values in the stack between threads for synchronisation for example.
nyanpasu64 5y ago
https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on-arm-program-compat-troubleshooter https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on... > You can also select multi-core settings, as shown here... These settings change the number of memory barriers used to synchronize memory accesses between cores in apps during emulation. Fast is the default mode, but the strict and very strict options will increase the number of barriers. This slows down the app, but reduces the risk of app errors. The single-core option removes all barriers but forces all app threads to run on a single core. https://news.ycombinator.com/item?id=28732273 https://news.ycombinator.com/item?id=28732273 zamadatix's interprets this as Microsoft saying that by default, Windows on ARM runs x86 apps without x86 TSO, and turns on extra memory barriers using per-app compatibility settings. But if an app needs TSO but isn't in Windows's database, it will crash or silently corrupt data.

xxs 5y ago

Normally the code should have all the needed memory fences as if running on DEC Alpha, e.g. linux does that, and the compilers omit the unneeded ones.

monocasa 5y ago
And since the compiler omitted it on x86, an x86 emulator doesn't have access to where they're required as seen by the compiler.
- xxs 5y ago
  emulator would have a zero issue, if it's a direct transfer for assembly (not an emulator), it'd need either hardware support - e.g. apple chips, or memory barriers. The differences between arm and x86 are known for 15y+, there is nothing new about it. Also concurrency support is one of the major benefits of languages with proper memory model - java started it with JMM[0] [0]: https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedL...
  - gpderetta 5y ago
    Any emulator that wants to be remotely performance competitive will do dynamic translation (i.e JIT). In fact ahead-of-time translation is not really feasible. Memory models and JVM are not really relevant when discussing running binaries for a different architecture.
    - secondcoming 5y ago
      Doesn't the JVM define its own memory model?
      - gpderetta 5y ago
        Sure, but how's that relevant when discussing running x86 binaries on ARM?