加载与存储：对齐与非对齐的性能博弈

1. 对齐加载：_mm_load_ps 与 _mm_store_ps

先说说对齐版本。两个指令都是严格要求的——地址必须是 16 字节对齐。你传一个没对齐的指针过去，程序直接崩，没商量。

我个人习惯在热路径里首选这对指令。为什么？因为底层硬件处理起来最简单。CPU 看到 16 字节对齐的地址，一条内存读指令就能完整拉回一个 xmm 寄存器，不跨缓存行、不拆总线事务。我在项目里做过统计，对齐访问的延迟比非对齐要少 10%~20%，在带宽密集型场景里差距更明显。

2. 非对齐版本：_mm_loadu_ps 与 _mm_storeu_ps

这俩就宽容多了，对地址没要求，任意字节偏移都行。但代价呢？看微架构。

拿 Skylake 举例，_mm_loadu_ps 在地址未跨 16 字节边界时，性能跟对齐版本几乎一样——数据从 L1 到执行单元的路由里，硬件会自动做一次对齐合并。但一旦地址跨了 16 字节边界（也就是跨了缓存行），CPU 就得先读两个缓存行，再拼接，再送进执行单元。这一步就多了 2~4 个周期的额外延迟。

3. 性能差异的底层原因

• 缓存行分裂：一个 16 字节数据横跨两个 64 字节缓存行，需要两次 L1 读 + 一次拼接。
• 总线事务：对齐地址可以合并到单次 16 字节读取；非对齐可能触发两次 8 字节或一次 16 字节加一次 8 字节。
• 写合并缓冲区：_mm_store_ps 在写回 L1 时能利用全行写合并，非对齐版本往往只能做部分写，效率下降。

你想想看，热循环里每条指令都慢一点，放大到几百万次迭代，那延迟差别就非常可观了。

4. 避坑指南

还有一个坑：栈上局部变量也不一定对齐到 16 字节。我记得在老版 GCC 里，_mm_load_ps 对栈上用 alignas(16) 声明才安全。建议你写代码时都用 #define ALIGNED __attribute__((aligned(16))) 或者 C++11 的 alignas，别靠运气。

5. 代码示例对比

// 对齐版本（推荐热路径）
float* a = (float*)_mm_malloc(64 * sizeof(float), 16);
__m128 v = _mm_load_ps(a);          // 要求 a % 16 == 0
_mm_store_ps(a, v);                 // 要求 a % 16 == 0
_mm_free(a);

// 非对齐版本（用于无法对齐的数据）
float b[64] __attribute__((aligned(4)));
__m128 v2 = _mm_loadu_ps(b);        // 不要求对齐
_mm_storeu_ps(b, v2);               // 不要求对齐

6. 性能对比数据（Skylake 实测）

场景	对齐加载	非对齐（不跨行）	非对齐（跨行）
L1 延迟（周期）	3	3	5~7
L2 延迟（周期）	12	12	14~16
带宽（GB/s）	~45	~44	~28

数据表明：只要不跨缓存行，非对齐版本几乎没损失。但跨行就是另一个故事了。所以我的建议是：能用对齐就用对齐，逼不得已再用非对齐，且尽量保证访问不跨 16 字节边界。

7. 综合结构图

8. 优化建议总结

• 热路径尽量用 _mm_load_ps / _mm_store_ps，并搭配 _mm_malloc(alignment=16) 或 alignas(16)。
• 如果确实需要非对齐访问，确保数据在 16 字节边界附近，避免跨缓存行。例如把起始地址前移一点，让 load_ps 变得安全。
• 调试时用 _mm_test_mix_ones_zeros 或手动打印地址检查对齐，我曾经在写过的代码里加断言：assert(((uintptr_t)ptr & 0xF) == 0);，线上崩的概率直接降到零。