6 ms·

Struggling with the use case. It seems like this is when you have the source or the libs but choose to mix x86 and arm? It would seem if you have the source e

Struggling with the use case. It seems like this is when you have the source or the libs but choose to mix x86 and arm? It would seem if you have the source etc you should just bite the bullet and port everything.

adamjs 2y ago
Two use-cases jump to mind: * Allows incremental porting of large codebases to ARM. (It's not always feasible to port everything at once-- I have a few projects with lots of hand-optimized SSE code, for example.) * Allows usage of third-party x64 DLLs in ARM apps without recompilation. (Source isn't always available or might be too much of a headache to port on your own.)
- callalex 2y ago
  At that point why trust the emulator over the port? Either you have sufficient tests for your workload or you don’t, anything else is voodoo/tarot/tea leaves/SWAG.
  - szundi 2y ago
    We might be lucky and the emulator guys might have enough testing
  - wtallis 2y ago
    "Why trust the emulator?" sounds a lot like asking "why trust the compiler?". It's going to be much more widely-used and broadly-tested than your own code, and probably more thoroughly optimized.
- frozenport 2y ago
  Yeah but you need to port the SIMD before shipping anyways? So if you're doing incremental stuff might as well stub out the calls with "not implemented", and start filling them in.
  - creshal 2y ago
    The SIMD part will be emulated as normal, as far as I understand. So you can ship a first version with all-emulated code, and then incrementally port hotspots to native code, while letting the emulator handle the non-critical parts. At least in theory, we'll see how it actually pans out in practice.
- vsl 2y ago
  3. Improve x64 emulation performance for everybody. Windows 11 on ARM ships system DLLs compiled as Arm64EC - makes the x64 binaries run native ARM code at least within system libraries.
- amelius 2y ago
  > Allows incremental porting of large codebases to ARM. (It's not always feasible to port everything at once-- I have a few projects with lots of hand-optimized SSE code, for example.) Wouldn't it make more sense to have a translator that translates the assembly, instead of an emulator that runs the machine code?
- ack_complete 2y ago
  It's not worth using ARM64EC for just for incremental porting -- it's an unusual mode with even less build/project support than Windows ARM64 and there are EC-specific issues like missing x64 intrinsic emulations and slower indirect calls. I wouldn't recommend it except for the second case with external x64 DLLs.
avidphantasm 2y ago
I feel like binary translation is a better approach. It’s a temporary workaround that allows users to use non-native programs while they are ported properly. ARM64EC seems like it will incentivize “eh that’s good enough” partial porting efforts that will never result in a full port, while making the whole system more complicated, with a larger attack surface (binary translation also makes the system more complicated, but it seems more isolated/less integrated with the rest of OS).
- PaulHoule 2y ago
  My understanding is that ARM64EC only makes sense in terms of binary translation. That is, the x64 bits get translated and the ARM bits don’t.
doctorpangloss 2y ago
Yes, bite the bullet and port. Of course it makes no sense. These sorts of things are only conceived in conversations between two huge corporations. Like Microsoft needs game developers to build for ARM. There’s no market there. So their “people” author GPT-like content at each other, with a ratio of like 10 middlemen hours per 1 engineer hour, to agree to something that narratively fulfills a desire to build games for ARM. I can speculate endlessly how a conversation between MS and EA led to this exact standard but it’s meaningless, I mean both MS and EA do a ton of things that make no sense, and I can’t come up with nonsense answers. Anyway, so this thing gets published many, many months after it got on some MS PM’s boss’s partner’s radar. Like the fucking devices are out! It’s too late for any of this to matter. You can’t play Overwatch on a Snapdragon whatever (https://www.pcgamer.com/hardware/gaming-laptops/emulation-proves-the-inevitable-achilles-heel-of-qualcomms-new-pc-chips-when-it-comes-to-gaming/ https://www.pcgamer.com/hardware/gaming-laptops/emulation-pr... ) End of story. Who cares what the ABI details are. Microsoft OWNS Blizzard and couldn’t figure this out. Whom is this for?
- comex 2y ago
  > Anyway, so this thing gets published many, many months after it got on some MS PM’s boss’s partner’s radar. Arm64EC is not new. It was released back in 2021.
anaisbetts 2y ago
The use-case is huge apps that have a native plugin ecosystem, think Photoshop and friends. Regular apps will typically just compile separate x64 and ARM64 versions

adamjs 2y ago

Two use-cases jump to mind: * Allows incremental porting of large codebases to ARM. (It's not always feasible to port everything at once-- I have a few projects with lots of hand-optimized SSE code, for example.) * Allows usage of third-party x64 DLLs in ARM apps without recompilation. (Source isn't always available or might be too much of a headache to port on your own.)

callalex 2y ago
At that point why trust the emulator over the port? Either you have sufficient tests for your workload or you don’t, anything else is voodoo/tarot/tea leaves/SWAG.
- szundi 2y ago
  We might be lucky and the emulator guys might have enough testing
- wtallis 2y ago
  "Why trust the emulator?" sounds a lot like asking "why trust the compiler?". It's going to be much more widely-used and broadly-tested than your own code, and probably more thoroughly optimized.
frozenport 2y ago
Yeah but you need to port the SIMD before shipping anyways? So if you're doing incremental stuff might as well stub out the calls with "not implemented", and start filling them in.
- creshal 2y ago
  The SIMD part will be emulated as normal, as far as I understand. So you can ship a first version with all-emulated code, and then incrementally port hotspots to native code, while letting the emulator handle the non-critical parts. At least in theory, we'll see how it actually pans out in practice.
vsl 2y ago
3. Improve x64 emulation performance for everybody. Windows 11 on ARM ships system DLLs compiled as Arm64EC - makes the x64 binaries run native ARM code at least within system libraries.
amelius 2y ago
> Allows incremental porting of large codebases to ARM. (It's not always feasible to port everything at once-- I have a few projects with lots of hand-optimized SSE code, for example.) Wouldn't it make more sense to have a translator that translates the assembly, instead of an emulator that runs the machine code?
ack_complete 2y ago
It's not worth using ARM64EC for just for incremental porting -- it's an unusual mode with even less build/project support than Windows ARM64 and there are EC-specific issues like missing x64 intrinsic emulations and slower indirect calls. I wouldn't recommend it except for the second case with external x64 DLLs.

avidphantasm 2y ago

I feel like binary translation is a better approach. It’s a temporary workaround that allows users to use non-native programs while they are ported properly. ARM64EC seems like it will incentivize “eh that’s good enough” partial porting efforts that will never result in a full port, while making the whole system more complicated, with a larger attack surface (binary translation also makes the system more complicated, but it seems more isolated/less integrated with the rest of OS).

PaulHoule 2y ago
My understanding is that ARM64EC only makes sense in terms of binary translation. That is, the x64 bits get translated and the ARM bits don’t.

doctorpangloss 2y ago

Yes, bite the bullet and port. Of course it makes no sense. These sorts of things are only conceived in conversations between two huge corporations. Like Microsoft needs game developers to build for ARM. There’s no market there. So their “people” author GPT-like content at each other, with a ratio of like 10 middlemen hours per 1 engineer hour, to agree to something that narratively fulfills a desire to build games for ARM. I can speculate endlessly how a conversation between MS and EA led to this exact standard but it’s meaningless, I mean both MS and EA do a ton of things that make no sense, and I can’t come up with nonsense answers. Anyway, so this thing gets published many, many months after it got on some MS PM’s boss’s partner’s radar. Like the fucking devices are out! It’s too late for any of this to matter. You can’t play Overwatch on a Snapdragon whatever (https://www.pcgamer.com/hardware/gaming-laptops/emulation-proves-the-inevitable-achilles-heel-of-qualcomms-new-pc-chips-when-it-comes-to-gaming/ https://www.pcgamer.com/hardware/gaming-laptops/emulation-pr... ) End of story. Who cares what the ABI details are. Microsoft OWNS Blizzard and couldn’t figure this out. Whom is this for?

comex 2y ago
> Anyway, so this thing gets published many, many months after it got on some MS PM’s boss’s partner’s radar. Arm64EC is not new. It was released back in 2021.

anaisbetts 2y ago

The use-case is huge apps that have a native plugin ecosystem, think Photoshop and friends. Regular apps will typically just compile separate x64 and ARM64 versions