.NET 上 x86/x64/ia64 内存模型之间的差异
我正在寻找有关 x86/x64/ia64 上 .NET CLR/JIT 使用的内存模型之间差异的参考。 我知道 x86 和 ia64 之间存在一些差异（指令重新排序、指令删除等），但我还没有找到有关 x86 和 x64 之间差异的参考。
我有一个应用程序的目标是一些非常严格的延迟数字，并且目前只能在 x86 上运行，也可能在 x64 上运行（绝对不能在 ia64 上运行）。 我想知道我是否可以依赖 x86 JIT 实现的一些工件，并且在 x64 上仍然相对安全，或者我是否应该对更宽松的 ia64 JIT 进行编程（这将需要更多的字段是易失性的，并且在多个字段中插入内存屏障）的地方）。
预先感谢您的任何指点。
I'm looking for a reference on the differences between the memory models used by the .NET CLR/JIT on x86/x64/ia64. I know there's some differences between x86 and ia64 (instruction reordering, instruction removal, etc.), but I haven't found a reference on the differences between x86 and x64.
I have an application that is aiming for some very tight latency numbers, and will only run on x86 at this time, and maybe on x64 (definately not on ia64). I'm wondering if I can rely on some artifacts of the x86 JIT implementation and still be relatively safe on x64, or if I should be programming to the looser ia64 JIT (which will require more fields be volitile and memory barriers be inserted in several places).
Thanks in advance for any pointers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
关于 .NET 内存模型（顺便说一句，它比 ECMA 模型更强）的两篇文章：
Joe Duffy 的书，Windows 上的并发编程，也是有关该主题的重要信息来源。
Two articles on the .NET memory model (which is stronger than the ECMA model, btw):
Joe Duffy's book, Concurrent Programming on Windows, is also a great source of information on this topic.
.NET 内存模型在 ECMA 规范 ISO/IEC-23271 中指定。 具体在第一部分：概念和架构，第 12.6 章“内存模型和优化”。
该标准定义了 JIT 可以运行的边界。如果您想对架构保持中立，则应该遵循该标准，而不是使用 x86/x64 JIT 的任何细节。
此外，x64 是 x86 的演进，它主要由附加指令、寄存器和一些扩展 (SSE2) 组成，被定义为所有 x64 兼容处理器的基准。 除了额外的地址空间和额外的寻址模式（指令指针相关数据访问）之外，内存模型几乎没有变化。因此，针对 x86 JIT 的优化应该也会在 x64 上产生良好的结果。
The .NET memory model is specified in the ECMA specification ISO/IEC-23271. Specifically in Partition I: Concepts and Architecture, Chapter 12.6 "Memory model and optimizations".
This standard defines the boundaries a JIT may operate in. If you want to be neutral to the architecture, you should follow this standard and not utilize any specifics of the x86/x64 JITs.
Additionally x64 is an evolution to x86, it consists mostly of additional instructions, registers and some extensions (SSE2) being defined as baseline for all x64 compliant processors. There's been almost no change to memory models, except for the additional address space and additional addressing modes (instruction pointer relative data access.) So optimizing for the x86 JIT should yield good results on x64 too.
这可能对你来说级别太低了，但一些较旧的 AMD 64 位 cpu 没有 CMPXCHG16B
（来源）如果您依赖它作为硬件非阻塞指令。
此外，似乎还有 C++ 的内存模型 这可能是相关的，因此如果您正在执行非常低级的代码，您可能必须留意。
CLR“指定”的内存模型是 Microsoft 内部持续争论的话题（至少可以追溯到 2003）。 作为旁注，Chris Brumme 在那篇文章中指出 x64 的模型与 x86 相同，我认为对于 CLR 托管代码来说这是一个准确的声明。
除非您的目标用户明确包含安腾，否则我认为只需包含一个后备、较慢但简单且安全的架构实现就足以保证正确性。 这样就无需表明您的软件在该平台上已损坏，只需表明它以较慢的回退模式运行即可。 如果人们随后想要认真使用该平台，您可以针对那个更加宽松的模型进行编码。
请注意，x64 JIT 与 x86 JIT 不同（自 3.5 SP1 起尤其如此），因此对其中一个的任何发布模式测试并不代表另一个，反之亦然。 酌情进行测试。
This may be far too low level you you but some older AMD 64 bit cpus do not have CMPXCHG16B
(Source) if you were relying on that as a hardware non-blocking instruction.
Also there seem to be changes in the memory model for C++ which may be relevant so you may have to keep an eye out if you are doing very low level code.
The memory model 'specified' by the CLR is an ongoing topic of debate within Microsoft (discussed openly at least as far back as 2003). As a side note Chris Brumme states in that article that the model of x64 is the same as x86 which I would assume is an accurate statement for the purposes of CLR hosted code.
Unless your target users explicitly include Itanium I would think that simply including a fallback, slower but simple and safe, implementation for that architecture would be sufficient for correctness. There is then no need to indicate that your software is broken on that platform, just that it operates in a slower fallback mode. If people subsequently want to use the platform seriously you can code to that much looser model.
Note that the x64 JIT is different to the x86 JIT (significantly so since 3.5 SP1) so any Release Mode testing on one is not representative of the other and vice versa. Test as appropriate.