avx加载非连续数据必须用avx2的_mm256_i32gather_ps等gather指令，因其支持单基址+8个独立偏移量加载；avx1不支持需降级为标量或索引表方案，且须注意scale匹配、越界静默错误及性能损耗。
AVX 加载非连续数据时不能直接用 _mm256_loadu_ps
这个函数只接受连续的 32 字节对齐（或未对齐）内存块，如果地址间隔不规则（比如数组索引是 arr[i*stride]），它会读错位置甚至崩溃。实际中常见于稀疏访存、跨行图像采样、间接寻址等场景。
- 错误现象：
segmentation fault或读出全零 / 随机值，尤其当 stride 是奇数或大于缓存行时 - 本质原因：AVX 的向量加载指令设计为“单基址 + 单偏移”，不支持运行时计算多个独立地址
- 替代方案不是“换一个更高级的 load 指令”，而是改用 gather 指令——但仅限 AVX2 及以上，且有代价
AVX2 _mm256_i32gather_ps 是唯一靠谱的通用解法
它允许你提供一个 base 地址 + 一个含 8 个 int32 偏移量的向量，一次性从 8 个非连续位置加载 float。但要注意：它不支持任意地址，只支持固定 scale（1/2/4/8）的偏移缩放。
- 典型用法：
_mm256_i32gather_ps(base_ptr, offset_vec, 4)表示取base_ptr[offset[i] * 4]，对应 float 数组 - 必须确保
offset_vec中每个值 × scale 后不会越界，否则行为未定义（不是抛异常，是静默读垃圾） - 性能比连续 load 低 3–5 倍：依赖 L1d 命中率，且部分 CPU（如早期 Haswell）gather 有额外延迟
- 如果数据在内存中是 double 类型，得用
_mm256_i32gather_pd，且 offset 要乘 8；类型和 scale 必须严格匹配
没有 AVX2？只能手动展开 + 标量回退
AVX1（Sandy Bridge）不支持 gather，此时硬上向量化反而拖慢。更现实的做法是识别模式，分情况处理：
- 如果非连续访问有小周期（例如 stride = 3，每 8 个元素重复一次），可预生成索引表 + 多路并行 load + shuffle 组合
- 如果只是偶尔跳几个元素（如 skip every 4th），不如用标量循环 + 编译器自动向量化（
-O3 -mavx有时能合成 blend） - 绝对不要手写 8 次
_mm256_set_ps(a[i], a[j], ...)—— 寄存器压力爆炸，且 store-to-load forwarding 会卡住流水线 - 调试时加断点看
offset_vec是否含负数或超大值：gather 指令对非法偏移不报错，只返回 0.0f
对齐、cache 和 aliasing 问题比想象中更敏感
即使用了 _mm256_i32gather_ps，实际性能仍可能被底层细节掐脖子：
- base 地址是否在 cache line 边界附近？如果 8 个目标分散在 4 个不同 cache line，带宽直接打七折
- 避免和 store 操作共享同一 cache line（false sharing），尤其多线程环境下——gather 本身不原子，但竞争会触发总线同步
- gcc/clang 对 gather 指令的寄存器分配不总是最优；强制用
__m256 t = _mm256_i32gather_ps(...);并立即参与计算，比存到临时变量再读更稳 - Intel 官方文档里没明说，但实测发现：当 offset 向量含大量重复值时，某些 CPU 会触发硬件去重逻辑，反而变慢
非连续访存从来不是“开了 AVX 就快”，关键在访存模式是否真能被硬件高效服务。与其强行塞进 256 位寄存器，不如先用 perf 看清 MEM_LOAD_RETIRED.L1_MISS 和 ARITH.FPU_DIV（gather 内部有除法微码）的实际占比。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
