.NET属性操作`x += y`与拆分写法的性能差异及版本/设备差异探究

1. 内存操作顺序为何引发显著性能差异 #

这种差异的核心原因在于CPU微架构对内存访问指令的处理逻辑差异，以及指令流水线的资源冲突：

• 你提到的反汇编操作数顺序差异，本质上对应两种不同的指令执行模式：
  • 拆分写法的汇编是典型的「读寄存器→计算→写内存」流程：先将属性值加载到CPU通用寄存器，完成加法运算后再写回内存。寄存器的读写延迟远低于内存，且这种流程能最大化利用CPU的流水线并行能力，减少内存访问的等待开销。
  • .NET 7中Prop_ReadWrite += i对应的汇编则是直接对内存地址执行「读-改-写」（RMW）操作（比如add [mem], reg这类指令）。这种指令需要CPU先从内存读取数据，在运算单元完成计算后立即写回内存，整个过程会占用内存总线的更多周期，且如果内存缓存未命中，或者CPU微架构对这类直接内存操作的优化不足，就会触发流水线停顿，导致性能下降。
• Intel与AMD设备的结果相反，是因为两者的CPU微架构对内存操作的硬件优化方向不同：
  • AMD部分微架构对直接内存操作的RMW指令支持效率较低，容易引发流水线阻塞；
  • Intel的微架构（比如Skylake及后续）对这类指令的调度更高效，甚至能通过硬件优化抵消部分内存访问的开销，因此出现反向的性能差异。

2. .NET 8中现象消失的原因：编译器优化的统一 #

.NET 8主要通过RyuJIT即时编译器的代码生成逻辑优化解决了这个问题：

• 在.NET 7中，RyuJIT对属性的复合赋值（+=）会直接生成针对内存地址的RMW指令；而拆分写法则会生成寄存器中转的指令，导致两种写法的汇编输出不一致。
• .NET 8中，RyuJIT优化了复合赋值的代码生成逻辑，对属性的+=操作不再直接生成内存操作指令，而是统一采用「寄存器中转」的模式——即先把属性值加载到寄存器，完成计算后再写回内存。这就使得两种写法的反汇编输出完全一致，自然消除了性能差异。
• 这个优化属于RyuJIT在.NET 8中针对内存操作指令调度的改进之一，目的是统一常见写法的编译输出，减少因语法写法差异导致的性能波动。

内容的提问来源于stack exchange，提问作者Celeste Soueid