直接用 _mm256_mul_ps 做逐元素乘法得不到矩阵乘结果，因为矩阵乘法是行与列的点积运算，而非逐元素相乘；该指令仅并行执行8个float乘法，后续需手动水平求和（如 _mm256_hadd_ps），效率低、寄存器压力大且无法隐藏访存延迟；高性能实现必须结合分块、预转置B矩阵、微内核累加及32字节内存对齐。
为什么直接用 _mm256_mul_ps 做逐元素乘法得不到矩阵乘结果
矩阵乘法不是逐元素相乘，而是 A 的行与 B 的列做点积。AVX2 本身不提供“向量点积”指令，_mm256_mul_ps 只负责 8 个 float 同时相乘，之后必须手动加和（如用 _mm256_hadd_ps 或 shuffle + add），但这样效率低、寄存器压力大，且无法隐藏访存延迟。
真正高性能的写法是分块（tiling）+ 微内核（micro-kernel）：把 C[i][j] 拆成多个 8×8 或 16×8 的小块，让每个 AVX2 寄存器承载一整行或一整列的中间累加值，用多组 _mm256_mul_ps + _mm256_add_ps 流水叠加，避免频繁 horizontal sum。
- 典型微内核会计算 16 行 × 8 列的 C 子块，每次加载 16 个 A 元素（沿行）、8 个 B 元素（沿列），用 8 个
__m256寄存器分别累积 8 列结果 - 必须对齐内存：A 按行主序、B 按列主序存储（或至少 B 被预转置），否则 cache miss 严重；使用
_mm256_load_ps要求地址 32 字节对齐，否则触发 #GP 异常 - 编译时加
-mavx2 -O3 -march=native，禁用-ffast-math（它可能破坏向量化语义）
如何避免 _mm256_store_ps 写回时的段错误和数据错位
最常见原因是目标数组未按 32 字节对齐，或写入长度不足（比如你用 8 个 float 的寄存器却只分配了 7 个元素空间）。AVX2 store 指令要求 dst 地址 % 32 == 0，否则运行时报 segmentation fault (core dumped)。
安全做法不是靠 runtime 检查，而是在分配时就强制对齐：
立即学习“C++免费学习笔记（深入）”；
- 用
aligned_alloc(32, size)（C11）或_mm_malloc(size, 32)（Intel intrinsics）分配内存 - 若用 std::vector，不能直接
data()—— 需包装：例如float* buf = (float*)_mm_malloc(n * sizeof(float), 32); - store 前确认剩余列数 ≥ 8：若 j 循环到末尾只剩 3 列，改用标量循环或
_mm256_maskstore_ps（需 AVX2 mask 支持，且注意 mask 是 int32 类型）
为什么转置 B 矩阵能大幅提升 AVX2 乘法吞吐
因为 AVX2 加载连续 8 个 float 效率最高，而标准矩阵乘中，B 是按列参与计算（C[i][j] += A[i][k] * B[k][j]），若 B 是行主序，取 B[k][j] 就是跨步访问，cache line 利用率极低。
- 预转置 B 为列主序（即新 B^T 是原 B 的转置，按行存），则 B^T[j][k] 连续存放，每次
_mm256_load_ps(&Bt[j * K + k])就能一次拉满 8 个 k 维元素 - 转置本身可用 AVX2 并行加速（8×8 分块转置），但首次开销大；适合多次复用同一 B 的场景（如推理中权重固定）
- 若 B 太大无法全量转置，可分块转置 + 多级缓存友好调度，避免 TLB miss
实际跑出来比 OpenBLAS 慢？检查这三点
手写 AVX2 微内核常输给高度调优的 OpenBLAS，不是指令问题，而是工程细节：
- 没做 loop unrolling：至少对 k 维 unroll 4–8 次，减少分支和指令 decode 压力；gcc 的
#pragma unroll 4不一定生效，建议显式展开 - 忽略 prefetch：在计算当前块前，用
_mm_prefetch(&A[i+4][k], _MM_HINT_NTA)提前拉取后续数据，掩盖 L2/L3 延迟 - 寄存器溢出：一个 16×8 微内核需至少 16 个
__m256寄存器（8 列 × 各自累加器），超出 AVX2 的 16 个 XMM/YMM 寄存器上限，导致 spill/reload —— 必须合并中间计算或降维分块
真正的瓶颈往往不在乘加本身，而在数据怎么喂进来、中间结果怎么暂存、以及不同层级 cache 之间怎么调度。写对指令只是第一步，对齐、分块、预取、寄存器分配，每一步漏掉都可能让速度跌掉一半。
