为何ARM NEON intrinsics实现奥赛罗合法棋步查找未快于原生C++？

核心原因分析 #

• 编译器自动向量化覆盖：Clang在-Ofast优化级别下，会自动将简单的64位位操作（and/or/移位等）编译为NEON指令。你手动编写的intrinsics代码，和编译器自动生成的标量代码的汇编输出几乎一致，自然没有性能差异。
• 超标量CPU的标量并行优势：M3芯片属于超标量架构，单周期内可执行多条标量位操作指令。对于延迟极低的简单位运算，标量指令的并行吞吐量已经能匹配甚至超过单条NEON指令的处理能力，SIMD的优势无法体现。
• 数据/指令开销抵消收益：如果你的NEON代码存在非对齐数据访问、频繁的标量-向量转换，或者函数未被内联，这些额外开销会完全抵消SIMD带来的性能提升。尤其是10亿次的高频调用，函数调用的固定开销占比会被放大。

针对性优化方案 #

• 对比汇编输出验证：用clang -S -Ofast -arch arm64编译原生C++和NEON版本代码，生成汇编文件后对比。如果两者指令序列高度重合，说明手动intrinsics完全多余，直接依赖编译器优化即可。
• 批量并行处理数据：不要用NEON单条处理64位棋盘数据，而是将2组/4组独立的棋盘数据打包为128位/256位向量，让SIMD一次处理多组计算，最大化吞吐量优势。比如同时计算多个落子位置的翻转结果，或者并行处理多局对局数据。
• 强制数据对齐：用alignas(16)或alignas(32)标记存储棋盘数据的变量/数组，确保NEON加载/存储指令使用对齐访问，避免额外的周期开销。
• 消除函数调用开销：给NEON实现的函数添加__attribute__((always_inline))属性，强制编译器内联该函数，尤其是高频调用场景下，内联能大幅降低调用开销。
• 重构算法适配SIMD：针对奥赛罗的核心翻转逻辑，重新设计算法以适配向量操作。例如，将多个方向的翻转检测合并到一次向量运算中，或者用向量掩码批量处理所有可能的翻转路径，减少循环分支和标量操作。
• 避免冗余转换：尽量在向量域内完成全部计算，减少vgetq_lane_u64/vmovq_n_u64这类标量-向量转换操作的使用，此类转换会引入额外的指令延迟。

内容的提问来源于stack exchange，提问作者Bruno Causse