目前应自己封装跨平台 SIMD：因 std::simd 尚未落地，需用三层结构（底层按指令集分文件、中间层运行时/编译时分发、上层统一接口），注意对齐差异、避免宏误替，并接受 NEON 与 AVX 数据布局差异。
用 std::simd（C++26）还是自己封装？
目前（2024 年中），std::simd 尚未在任何主流编译器中完全落地——GCC 14 实验性支持但默认禁用，Clang 18 仅限部分目标且需 -fexperimental-library，MSVC 完全未实现。指望标准库跨平台 SIMD 还得再等一两年。所以现在写跨平台 SIMD，实际就是「手动桥接不同后端」：用宏 + 条件编译把 _mm_add_ps、vaddq_f32、vec_add 等统一成一套接口。
如何组织头文件和编译条件判断
核心是避免在每个 .cpp 里重复写 #ifdef __AVX2__ 或 #ifdef __aarch64__。推荐一个三层结构：
- 底层：按指令集分文件，如
simd_avx2.h（含_mm256_load_ps调用）、simd_neon.h（含vld1q_f32）、simd_generic.h（纯 C++ 循环回退） - 中间层：
simd_dispatch.h，用__builtin_cpu_supports("avx2")（GCC/Clang）或IsProcessorFeaturePresent(PF_AVX2_INSTRUCTIONS_AVAILABLE)（MSVC）做运行时分发，或用编译期宏（如defined(__AVX2__)）做编译时选择 - 上层接口：
simd_vec4f_add(a, b)这类函数，只包含simd_dispatch.h，不暴露任何底层细节
容易踩的坑：__AVX2__ 宏只在编译器启用 AVX2 时定义（如 -mavx2），但不代表 CPU 支持；而 __builtin_cpu_supports 是运行时检测，必须确保调用前已初始化 CPU 特性缓存，否则首次调用有分支预测开销。
_mm256_load_ps 和 vld1q_f32 的内存对齐差异
x86 的 _mm256_load_ps 要求 32 字节对齐，否则触发 EXCEPTION_ILLEGAL_INSTRUCTION（Windows）或 SIGBUS（Linux）；ARM NEON 的 vld1q_f32 对未对齐地址容忍度高，但性能下降明显（多一次内存访问）。两者语义不等价，不能简单宏替换。
立即学习“C++免费学习笔记（深入）”；
- 统一做法：所有 SIMD 向量输入/输出指针加
alignas(32)声明，或用aligned_alloc(32, size)分配 - 若无法控制上游内存（如第三方 API 返回的 float*），改用带“u”后缀的加载函数：
_mm256_loadu_ps/vld1q_f32（NEON 本就无严格对齐要求，但 x86 必须显式用 u 版） - Clang/GCC 对
loadu在 AVX2 下会生成vmovups，比vmovaps多 1–2 个周期，但安全第一
为什么不用 ISPC 或 Halide？
它们确实能自动生成多平台 SIMD，但引入了新 DSL、构建依赖和运行时调度器，和 C++ 工程耦合重。如果你只是想加速某几个热点函数（比如图像卷积、向量归一化），手写封装更轻量、调试更直接、编译产物更可控。
- ISPC 编译出的函数需通过
ispc_rt运行时调用，无法内联，函数调用开销明显 - Halide 默认生成 JIT 代码，启动慢；AOT 模式需为每种 target 单独编译，CI 构建矩阵爆炸
- 手写封装可精确控制向量化粒度（比如只对 inner loop 向量化，外层保持标量逻辑），而 DSL 往往强制整块重写
真正麻烦的是 NEON 和 AVX 的数据布局差异：ARM 默认小端+lane-wise，x86 是 element-wise，做 shuffle 时（比如转置 4×4 矩阵）得分别写两套 transpose4x4 实现，没法靠宏一把梭。这点几乎没法绕开，只能接受。
