AVX2矩阵乘法不能直接用_mm256_mul_ps，因其仅执行逐元素乘法（Hadamard积），而矩阵乘法需行×列点积；正确做法是分块转置B、寄存器累加并显式初始化零值。
AVX2矩阵乘法为什么不能直接用_mm256_mul_ps？
因为 _mm256_mul_ps 只做逐元素乘法，而矩阵乘法本质是“行×列求和”，需要先广播（broadcast）一个向量、再累加点积。直接套用会得到错误结果，且无法利用好寄存器带宽。
- 典型错误：把 A 的一行和 B 的一列都 load 成
__m256，然后_mm256_mul_ps—— 这只算出了 8 个对应位置乘积，漏掉了求和步骤 - 正确路径：对 B 的某列分块 broadcast 到多个 lane，用
_mm256_dp_ps（如果支持）或手动展开的 FMA 序列实现点积 - AVX2 本身不支持单指令点积（
_mm256_dp_ps是 AVX-512 才有的），所以必须用_mm256_mul_ps+_mm256_add_ps多轮累加，或改用 FMA 指令（_mm256_fmadd_ps）——它要求 CPU 支持 FMA3（如 Haswell 及以后）
如何组织数据布局才能让 AVX2 计算不卡顿？
内存对齐和访问模式比指令本身更容易成为瓶颈。行主序（row-major）下，A 的行连续，但 B 的列不连续 —— 直接访存会引发大量 cache miss 和 unaligned load penalty。
- 必须将 B 转置为 BT（列变行），使 BT 的行对应原 B 的列，这样 A 的一行 × BT 的一行 = 点积，且两者都是连续访存
- 所有输入数组需 32 字节对齐：
aligned_alloc(32, size)或std::aligned_alloc（C++17），否则_mm256_load_ps可能 crash 或降速 - 推荐分块（tiling）：按 8×8 或 16×8 块调度，让每块尽量 fit L1 cache（通常 32KB），避免 TLB miss。例如：内层循环处理 8 行 A 和 8 列 BT（即 8×8 结果块）
并行时线程间怎么避免写冲突和 cache 乒乓？
结果矩阵 C 的每个元素 C[i][j] 理论上可独立计算，但 naive 的 omp parallel for(i) for(j) 会导致 false sharing —— 多个线程往相邻 cache line 写不同列，却因同一 64 字节 line 被反复 invalid。
- 禁止按行或按列简单并行：
#pragma omp parallel for套两层循环极易触发 false sharing - 正确做法：按 8×8 或 16×16 的结果块划分任务，每个线程处理一个完整 block，保证写内存局部性
- 使用 private 累加器：
__m256 sum0, sum1, ...在寄存器中累积中间结果，最后一次性 store 到 C，减少对 C 的写频次 - OpenMP 最好配
schedule(dynamic, 8)，避免负载不均（尤其当 M/N/K 不整除块大小时）
实际跑起来比 OpenBLAS 慢很多？检查这三点
手写 AVX2 很难超越高度调优的 OpenBLAS，除非你针对特定尺寸和硬件做了深度适配。常见差距来源很具体：
立即学习“C++免费学习笔记（深入）”；
- 没启用 FMA：确认编译加了
-mfma -mavx2，且运行在支持 FMA 的 CPU 上（cat /proc/cpuinfo | grep fma）；否则_mm256_fmadd_ps会被降级成 mul+add 两条指令 - 没做 prefetch：对即将用到的 B（或 BT）数据提前
_mm_prefetch，尤其在大矩阵时能显著降低 stall - 没绕过 store-forwarding stall：不要用
_mm256_store_ps紧接着_mm256_load_ps写同一地址；C 的写入应滞后于计算，或用 non-temporal store（_mm256_stream_ps）配合_mm_sfence，但仅当 C 不会被立即读取时才安全
真正高效的实现不是堆指令，而是让数据在 cache 层之间“滑”得顺畅。寄存器重用、prefetch 时机、store 策略——这些细节不报错，但决定你是快 2 倍还是慢 3 倍。
