AVX2矩阵乘法不能直接套用_mm256_mul_ps，因为它仅执行逐元素乘法（Hadamard积），而矩阵乘法本质是行×列点积，需广播、累加和显式求和；必须配合分块、B预转置、32字节对齐、循环展开及寄存器累加才能正确高效实现。
AVX2矩阵乘法为什么不能直接套用_mm256_mul_ps逐元素相乘？
因为矩阵乘法本质是“行×列求和”，不是逐元素运算。直接用_mm256_mul_ps只能做点积中间步骤，真正关键的是累加——而_mm256_add_ps必须和循环展开、寄存器重用配合，否则会因频繁读写内存或寄存器冲突严重拖慢速度。
常见错误是把A[i][k] * B[k][j]改成向量化后，仍用单层k循环，导致每次加载都触发cache miss；或者没对齐内存，触发segmentation fault或降级到SSE路径。
- 必须按块（tiling）划分：典型取
M=16, N=16, K=48适配AVX2的256位宽度（8个float） - 输入矩阵需
_mm256_load_ps，要求地址对齐到32字节——用aligned_alloc(32, size)或std::vector加自定义分配器 - 避免依赖链：用多个累加寄存器（如
sum0~sum3）交错计算，填满CPU发射端口
AVX-512下_mm512_dpbf16_ps为何只适合BF16，且必须配合_mm512_cvtne2ps_bf16？
因为_mm512_dpbf16_ps是专用BF16点积指令，不支持FP32/FP16输入，也不能直接加载BF16数据——它只接受两个__m512bh（即32个BF16），输出一个__m512（16个FP32）。所以必须先用_mm512_cvtne2ps_bf16把两组BF16转成FP32中间表示，再喂给点积指令。
实际部署时容易忽略硬件支持条件：dpbf16仅在Sapphire Rapids及更新CPU上可用，老款Xeon（如Ice Lake）会报illegal instruction。
立即学习“C++免费学习笔记（深入）”；
- 编译需加
-mavx512bf16 -mavx512vl，且运行时用cpuid检测AVX512_BF16标志位 - BF16矩阵需按行连续存储，每2个BF16组成一个
uint32_t低16位，否则_mm512_cvtne2ps_bf16解包错乱 - FP32累加结果要手动截断回BF16再存，否则精度溢出——用
_mm512_cvtps_ph而非_mm512_cvtps_pbh（后者不存在）
如何避免AVX指令在多线程下引发frequency throttling？
AVX-512全宽指令（如_mm512_mul_ps）会让CPU进入高功耗状态，触发Intel的AVX512频率限制机制，导致同一物理核上其他线程变慢。这不是bug，是硬件设计使然。
单纯用pthread_setaffinity_np绑核解决不了问题——关键是要控制指令宽度和线程密度。
- 混合负载场景下，优先用AVX2而非AVX-512：通过
__builtin_ia32_getarch运行时选择指令集路径 - OpenMP中禁用嵌套并行，设置
OMP_NUM_THREADS=min(总核数, 逻辑核数/2)留出余量 - Linux下可临时关闭降频：写
/sys/devices/system/cpu/intel_pstate/no_turbo为0，但仅限测试环境
std::vector和手动aligned_alloc在AVX性能差异有多大？
差别显著。默认std::vector<float></float>分配内存通常只保证16字节对齐，而AVX2需要32字节，AVX-512需要64字节。未对齐触发_mm256_load_ps时，要么崩溃，要么 silently fallback 到慢速路径（实测吞吐下降40%+）。
有人用std::vector加alignas(32)，但这只对栈对象有效，堆上无效；也有人用std::allocator特化，但标准库实现未必透传对齐请求。
- 最稳方案：用
float* ptr = (float*)aligned_alloc(64, size * sizeof(float))，配合std::unique_ptr<float void></float>管理 - Clang/GCC下可用
__attribute__((aligned(64)))修饰全局数组，但不可用于动态大小 - Windows上用
_aligned_malloc，注意对应_aligned_free，不能混用free
实际写内核时，最易被忽略的是内存访问模式与缓存行竞争——即使指令全向量化，若A矩阵按行访存而B按列访存，L3 cache利用率可能低于30%。这时候再优化指令也没用，得先改数据布局。
