\_mm256\_mul\_ps 仅支持逐元素乘（hadamard积），无法直接实现矩阵乘；正确做法是分块、预转置b、显式对齐内存、手动向量化累加，并配合预取与寄存器优化。
直接套用 _mm256_mul_ps 或 _mm512_mul_ps 写三层循环，性能大概率比标量还差——瓶颈不在算力，而在内存供给没跟上、寄存器没管住、指令混用触发降频。
为什么 _mm256_mul_ps 不能直接用于矩阵乘
它只做逐元素相乘（Hadamard 积），而矩阵乘要求的是行×列点积：C[i][j] = Σ A[i][k] * B[k][j]。用 _mm256_mul_ps 算出来的根本不是矩阵乘结果，而是错位的垃圾值。
- 常见错误现象：结果全为 0、数值溢出、或输出明显偏移（比如 C[0][0] 实际填到了 C[0][1]）
- 真正该用的是累加展开策略：加载 A 的一行（8 float）、B 转置块的一列（8 float），循环 8 次
_mm256_mul_ps+_mm256_add_ps到初始化为零的__m256寄存器 -
_mm256_dp_ps在 AVX2 上不支持浮点点积；AVX-512 的_mm512_dpbf16_ps或_mm512_fmadd_ps才能单指令完成部分点积，但需 BF16 输入或额外掩码控制
内存对齐和分配必须显式控制
AVX2 要求 _mm256_load_ps 的地址是 32 字节对齐的，否则在部分 CPU 上直接触发 #GP 异常，另一些则静默退化成标量路径，性能掉 3–5 倍。
- 别用
new float[n]或std::vector<float></float>——它们几乎从不对齐 - 改用
_mm_malloc(size, 32)分配，_mm_free(ptr)释放；或aligned_alloc(32, size)（需保证size % 32 == 0） - 验证对齐：
(uintptr_t)ptr & 31必须恒为 0 - 声明栈数组时加
alignas(32) float A[1024]; - 函数入口加
_mm256_zeroupper()，防止调用外部库时 SSE 指令被拖慢
分块 + 预转置 + 预取，三者缺一不可
没分块，L1d 缓存缺失率轻松超 70%；没预转置，B 的列访问就是随机访存；没预取，CPU 有 12–15 cycle 空等，AVX 单位根本吃不饱。
- 外层按 64×64 分块（适配 L2 容量），内层用 8×8 tile（匹配 AVX 的 8 float 并行度）
- B 必须预转置成行主序小块（如 8×8），让
_mm256_load_ps能连续取满 8 个 float；现场用transB ? B[j * ldb + k] : B[k * ldb + j]会打断流水线且更慢 - 预取用
_mm_prefetch(&A[i + 64], _MM_HINT_NTA)拉后续 A 块；对 B 沿列方向每 8 行预取一次：_mm_prefetch(&B[(t + 8) * ldb + j], _MM_HINT_NTA) - 禁用编译器自动向量化：
-fno-tree-vectorize，避免它生成与手写混合的冲突指令
AVX2 和 AVX-512 不是简单替换关系
AVX-512 不是“更快的 AVX2”，它带来寄存器压力翻倍、功耗墙触发降频、部分 CPU 上 512-bit 指令吞吐只有 256-bit 的一半。盲目启用可能反而变慢。
- AVX2 更稳：所有主流 x86-64 CPU（包括 AMD Zen2+）都支持，且 256-bit 指令能维持基础频率
- AVX-512 需运行时检测：
__builtin_cpu_supports("avx512f")，且必须 fallback 到 AVX2 路径；Ice Lake / Sapphire Rapids 上若未关闭 turbo boost，double-precision 吞吐未必提升 - 别硬塞进一个函数处理 trans/batch 场景：指针偏移、ldA/ldB 计算、stride 更新极易出错；统一用指针偏移更新（
A += b_stride）比条件分支更可靠
最易被忽略的点是：对齐验证、分块尺寸与缓存层级的匹配、以及预取位置是否真正覆盖了下一轮计算所需数据——这三者稍有偏差，AVX 就从加速器变成拖油瓶。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
