做底层优化这些年，被问得最多的问题之一就是“为什么同样的算法，别人跑出来比我快好几倍”。排除掉算法复杂度、内存布局这些因素之后，剩下的差距往往就落在一条线上——有没有把 SIMD 用起来。SIMD，全称 Single Instruction Multiple Data，单指令多数据，说白了就是让一条 CPU 指令同时处理一批数据，而不是一次只啃一个。这个技术在图像处理、音视频编解码、科学计算、机器学习推理、密码学实现里几乎是标配，但很多写上层业务的朋友对它一直停留在“听说过”的阶段，觉得那是编译器或者库作者才需要关心的事。实际情况是，只要你写过稍微密集一点的循环，理解 SIMD 就能让你对自己的代码性能有一个完全不同的判断视角。

这篇内容我打算按一线优化的实际思路来拆：先讲清楚 SIMD 到底在硬件层面是怎么回事、为什么它能快，再落到具体的技术路线选择（编译器自动向量化、intrinsic 手写、库封装三条路各自的取舍），然后是实操环节里最容易被忽略的细节——数据对齐、循环边界处理、归约操作的写法，最后把我这些年踩过的坑整理成一份排查清单。适合有一定 C/C++ 或 Rust 基础、想搞清楚性能瓶颈到底在哪的开发者，也适合做算法落地、需要判断“这段代码还有没有优化空间”的工程同学。哪怕你暂时不打算手写 SIMD，读完至少能判断出编译器有没有帮你把活干了。

1. 先把 SIMD 的账算明白：它到底快在哪

很多人对 SIMD 的理解停留在“一次算四个数所以快四倍”，这个说法对了一半，但漏掉了最关键的部分。要真正理解它，得从 CPU 的执行单元结构说起，而不是从“并行”这个抽象词开始。

1.1 从标量流水线到向量执行单元的硬件逻辑

传统标量指令的执行模型是：取指、译码、取操作数、执行、写回，一条指令处理一个数据。现代 CPU 为了提升吞吐，搞了流水线、超标量、乱序执行，但这些手段本质上是在“让多条指令重叠执行”，单条指令的数据吞吐量并没有变。SIMD 走的是另一条路：在 CPU 里放一组更宽的寄存器和对应的执行单元，一条指令就能把寄存器里打包的多个数据同时算完。

打个生活化的比方。标量计算像是一个人搬砖，一次搬一块，想快就得多雇几个人（多核、多线程）；SIMD 像是给这个人换了一辆手推车，一次推一车砖，人还是一个人，但单位时间搬运量上去了。这两条路线是正交的，可以叠加——多核加 SIMD 就是既多雇人又配推车。

具体到寄存器宽度，这是理解 SIMD 性能上限的第一个关键数字。x86 平台上经历了 MMX（64 位）、SSE（128 位）、AVX/AVX2（256 位）、AVX-512（512 位）几代演进；ARM 平台则是 NEON（128 位固定），以及 ARMv9 之后引入的 SVE/SVE2（可变长度，128 到 2048 位）。以 128 位寄存器装 32 位整数为例，一条指令能同时处理 4 个；换成 256 位就是 8 个；浮点数同理。这个“几个”就是理论上的并行度，也叫向量宽度。

但理论并行度不等于实际加速比，这是新手最容易误判的地方。原因在于：第一，数据得能连续装进寄存器，装填和取出本身有开销；第二，不是所有运算都有对应的向量指令，比如某些复杂的超越函数、除法、开方，向量版本的延迟和吞吐跟标量版本的比例并不是简单的一比四；第三，内存带宽往往是真正的瓶颈，向量单元算得再快，数据供不上也是白搭。所以实际项目里，SIMD 带来的加速从 1.5 倍到 8 倍都见过，取决于运算密度和数据规模。

1.2 为什么“数据并行”比“指令并行”更适合密集循环

这里要区分两个概念：指令级并行（ILP）和数据级并行（DLP）。指令级并行靠的是 CPU 乱序执行引擎在指令流里找互不依赖的指令重叠执行，编译器也能做指令调度来提升 ILP。但 ILP 有个天花板：程序里天然可并行的独立指令数量有限，而且寄存器重命名、重排序缓冲这些硬件资源也是有限的。

数据级并行不一样，它的并行性来自数据本身。一个对数组每个元素做同样操作的循环，天然就有 N 倍的并行度，N 是数组长度。这种“同一操作作用于大量数据”的模式在数值计算里极其普遍——图像每个像素做色彩变换、音频每个采样点做滤波、矩阵每个元素做累加，全是这个形状。SIMD 就是为这种模式量身定做的。

我常跟人讲一个判断标准：如果你的热点循环体里，每次迭代做的事情几乎一样，且迭代之间没有复杂的数据依赖，那它大概率能被向量化，也大概率值得向量化。反过来，如果循环体里有大量分支、间接寻址、链表跳转，那 SIMD 帮不上什么忙，该考虑的是换数据结构或者换算法。这个判断不需要你会写 intrinsic，只需要你能看懂循环的形状。

1.3 一个具体的加速比估算，别凭感觉

拿一个典型的例子算笔账：对长度为 N 的 float 数组做逐元素乘加（a[i] = a[i] * b + c）。标量版本每次迭代做一次乘一次加，假设 CPU 主频 3GHz，乘加各一个周期（实际有流水线，吞吐更高，这里简化），理论上是每 2 个周期处理一个元素。用 AVX2 的 256 位寄存器，一次装 8 个 float，一条 FMA（融合乘加）指令搞定 8 个元素的乘加，理论上每 1 个周期处理 8 个元素。粗算下来理论加速比接近 16 倍。

但实测往往只有 4 到 6 倍。差在哪？内存带宽。8 个 float 是 32 字节，加上读 b、读 c，每次迭代要搬运接近 96 字节的数据。当数组大到超出各级缓存、必须走主存时，带宽就成了硬约束，向量单元再宽也只能干等。这也解释了一个常见现象：小数组上 SIMD 加速明显，大数组上加速比被内存带宽吃掉一大截。所以做性能评估时，一定要区分数据规模是落在 L1、L2、L3 还是主存，不同层级的结论可能完全相反。

提示：估算 SIMD 收益时，先算“计算密度”——每搬运一字节数据要做多少次运算。密度越高，SIMD 越划算；密度低（比如纯拷贝、简单赋值），瓶颈在带宽，向量化收益有限。

2. 三条技术路线怎么选：自动向量化、intrinsic、封装库

搞清楚原理之后，落地时有三条路可走，各有各的适用场景和坑。选错路线要么白费力气，要么引入难以维护的代码。我按“介入程度从低到高”的顺序讲。

2.1 编译器自动向量化：免费但不保证

现代编译器（GCC、Clang、MSVC、ICC）都带自动向量化能力，在合适的优化级别下（GCC/Clang 的 -O3，MSVC 的 /O2 加特定开关），编译器会分析循环，判断能否安全地转成向量指令。这条路零成本，代码不用改，是应该优先尝试的。

但“能向量化”和“真的向量化了”是两回事。编译器非常保守，只要它无法证明循环迭代之间没有依赖，就会放弃向量化。常见的阻碍包括：指针可能存在别名（编译器不知道两个指针是否指向同一块内存）、循环里有函数调用、有数据依赖的跨迭代访问、循环次数在编译期未知且编译器不敢做运行时检查。这些情况下，编译器会老老实实生成标量代码，而且默认不告诉你。

所以第一步永远是让编译器开口说话。GCC 和 Clang 有专门的报告开关：

# GCC：输出向量化决策详情 gcc -O3 -fopt-info-vec-all -c kernel.c # Clang：输出向量化报告 clang -O3 -Rpass=loop-vectorize -Rpass-missed=loop-vectorize -c kernel.c

看输出里的 “vectorized” 和 “missed” 字样，就能知道哪个循环被向量化了、哪个没有、原因是什么。我见过太多项目拍脑袋说“开了 -O3 就自动向量化了”，结果一查报告，热点循环因为一个指针别名问题全程标量执行。这个检查动作花不了五分钟，收益却可能是几倍的性能差距。

消除阻碍的常用手段：给指针加restrict（C）或引用加限定（C++）告诉编译器不重叠；把循环体内的函数调用改成内联；用#pragma omp simd或#pragma GCC ivdep显式告诉编译器“我保证没依赖”。这些是低成本的干预，值得先试。

2.2 Intrinsic 手写：控制力最强，维护成本也最高

当自动向量化搞不定，或者你需要榨干最后一点性能时，就得上 intrinsic。Intrinsic 是编译器提供的内建函数，一一对应到底层的向量指令，比如_mm256_add_ps对应 AVX 的 256 位浮点加法。它比写汇编友好得多（寄存器分配、指令调度交给编译器），又比自动向量化可控得多。

代价是可移植性。x86 的 intrinsic 和 ARM 的 NEON intrinsic 是两套完全不同的 API，函数名、类型、语义都有差异。一份代码想同时跑在两个平台上，要么写两套，要么用条件编译包起来，要么借助一些跨平台的抽象层。这是 intrinsic 路线最大的工程负担，项目里如果没有明确的性能刚需和持续维护的人力，我不建议大面积手写。

一个最小的 AVX2 例子，感受一下写法：

#include <immintrin.h> void add_arrays(float* a, const float* b, int n) { int i = 0; // 每次处理 8 个 float for (; i + 8 <= n; i += 8) { __m256 va = _mm256_loadu_ps(a + i); __m256 vb = _mm256_loadu_ps(b + i); __m256 vc = _mm256_add_ps(va, vb); _mm256_storeu_ps(a + i, vc); } // 处理尾部剩余元素 for (; i < n; ++i) { a[i] += b[i]; } }

这段代码里有两个细节值得说。loadu的 u 表示 unaligned，即不要求内存对齐，性能略低于对齐版本但通用性强；循环分成主循环和尾部处理两段，主循环按向量宽度步进，尾部用标量补齐，这是所有手写 SIMD 的标准骨架，后面会专门展开讲边界处理。

2.3 封装库与语言内建：性价比最高的中间地带

如果你不想被 intrinsic 的平台差异绑死，又想要比自动向量化更强的控制力，中间地带是使用成熟的封装库或语言内建机制。这类方案把平台差异藏在底层，上层提供统一的向量类型和操作。

C++ 生态里，Eigen、xsimd、Vc（现在叫 std-simd 的前身之一）都是常见选择，它们提供向量类型，运算符重载让代码看起来像标量代码，编译时映射到对应平台的指令。Rust 的std::simd（nightly）和packed_simd走的是类似思路。数值计算领域更省事，直接用 BLAS 实现（如 OpenBLAS）或者高层库，矩阵运算的向量化人家早就做好了，你调就行。

这条路线的取舍很清楚：开发效率高、可移植性好、代码可读性强，代价是可能损失一点极限性能（封装层的抽象有时会阻碍编译器做最优调度），以及受制于库的成熟度和维护状态。对绝大多数业务场景，这是性价比最高的选择。真正需要手写 intrinsic 的，通常是库作者、编解码器实现者、或者对延迟极度敏感的底层模块。

3. 手写 SIMD 的实操骨架：从对齐到边界一个都不能少

假设你已经决定手写，或者至少要读懂别人写的向量代码，那有几个环节是绕不过去的。这一节按实际编码顺序展开，每个环节都讲清楚“为什么这么做”而不只是“怎么做”。

3.1 数据对齐：为什么它值那点额外功夫

内存对齐指的是数据的起始地址是某个值的整数倍。SIMD 的对齐加载指令（如_mm256_load_ps）要求地址按向量宽度对齐（AVX2 是 32 字节），不对齐会直接触发异常崩溃；而对齐加载通常比非对齐加载（loadu）有更好的性能，尤其是在跨越缓存行边界时。

为什么对齐能快？因为 CPU 访问内存是以缓存行为单位（通常 64 字节）的。一个 32 字节的向量如果起始地址没对齐，很可能横跨两个缓存行，需要两次内存访问再拼接，延迟和带宽都翻倍。对齐之后，一次访问搞定。

实操上，分配对齐内存有几种方式：C11 的aligned_alloc、POSIX 的posix_memalign、编译器扩展__attribute__((aligned(32)))，C++17 之后还有std::aligned_alloc。我一般封装一个分配函数，统一按 64 字节对齐（覆盖 AVX-512 和缓存行），省得后面反复算。

// 按 64 字节对齐分配，size 需为对齐值的整数倍 void* ptr = aligned_alloc(64, ((n * sizeof(float) + 63) / 64) * 64);

注意：对齐分配的内存必须用对应的释放函数（free通常可以，但某些平台要求配对），而且分配大小要是对齐值的整数倍，否则行为未定义。这个细节坑过不少人。

如果数据来源不受你控制（比如外部传入的缓冲区），那就老老实实用loadu，别为了追求对齐去做数据拷贝——拷贝的开销往往比非对齐访问的损失还大。对齐是优化手段，不是正确性要求，这个优先级要摆正。

3.2 循环边界处理：主循环加尾部的标准套路

向量宽度是固定的（比如 8 个 float），但数组长度几乎不可能是 8 的整数倍。所以标准做法是把循环拆成两段：主循环按向量宽度步进，处理所有完整的向量块；剩下的不足一个向量的元素，用标量循环补齐。这就是 2.2 节例子里那个结构的由来。

尾部处理看着简单，但有两个坑。第一，尾部循环的步进和边界条件容易写错，尤其是当向量宽度和元素类型大小挂钩时（比如处理 int16 时 256 位寄存器装 16 个），算错一个下标就是越界。第二，尾部标量代码虽然只处理少量元素，但如果数组很短（比如长度小于向量宽度），整个函数就退化成纯标量，向量化的收益为零。所以对短数组要有心理预期，别指望 SIMD 救场。

还有一种更激进的做法叫“重叠处理”：主循环处理到倒数第二个向量块，最后一个向量块从n - 向量宽度处开始，与前面的块重叠一部分，这样就不需要单独的尾部循环。代价是重叠部分的元素被计算了两次，如果操作是幂等的（比如纯赋值、取最大值）没问题，如果是有副作用的累加就不行。这个技巧在图像处理里很常见，用之前先确认操作语义。

3.3 归约操作：向量化里最反直觉的一环

逐元素操作（a[i] = f(b[i])）向量化很直观，但归约操作（比如求和、求最大值）就不一样了。标量求和是一个累加器从头加到尾，天然串行；向量化之后，你得用多个累加器分别累加不同的向量通道，最后再把它们合并。这个“水平合并”（horizontal reduction）步骤是归约向量化的核心，也是最容易写错的地方。

以 float 数组求和为例，思路是：维护一个向量累加器，主循环里把每个向量块加到累加器上；循环结束后，把累加器里的 8 个 float 水平相加得到一个标量；再加上尾部元素。水平相加有专门的指令（如_mm256_hadd_ps），但它的行为比较绕（会做交叉排列），实际项目里更稳妥的做法是把向量存回数组再标量求和，或者用移位加加法手动归约。

这里有个精度问题必须提。浮点加法不满足结合律，向量化改变了求和顺序，结果和标量版本可能有微小差异。对大多数场景无所谓，但对数值敏感的计算（比如某些累加器、金融计算），这个差异可能不可接受。我遇到过因为向量化求和导致对账差几分钱的案例，排查了半天才发现是求和顺序变了。涉及金额、涉及严格数值复现的场景，归约向量化要慎用，或者用 Kahan 求和之类的补偿算法。

3.4 分支与掩码：向量化最怕的东西

循环体里的 if-else 是向量化的大敌。标量代码里分支预测能处理得很好，但向量化之后，一个向量里的不同通道可能走不同分支，硬件没法“部分执行”。解决办法是掩码（mask）：把条件算成一个布尔向量，然后用掩码选择指令（blend）在两个结果之间按通道选择，相当于把分支变成无分支计算。

AVX-512 原生支持掩码寄存器，写起来比较自然；AVX2 及更早的平台没有掩码寄存器，得用比较加 blend 指令模拟，代码会啰嗦一些。NEON 也有类似的选择指令。这个转换的代价是：原本一个分支跳转，现在变成比较加选择两条指令，如果分支很少触发，反而可能变慢。所以不是所有分支都值得向量化，得看分支的分布——如果条件在数据上高度不均匀（比如 90% 走一个分支），标量加分支预测可能更快；如果条件随机分布，掩码方案更稳。

4. 踩坑实录：那些文档里不会写的排查经验

理论和骨架讲完，真正拉开差距的是实操中遇到的各种意外。这一节我把这些年积累的问题整理成速查表，每条都附上排查思路，都是真金白银换来的。

4.1 常见问题速查表

4.2 编译器报告里的“假阴性”与“假阳性”

看向量化报告时要有辨别力。有时候报告说“vectorized”，但实际生成的代码里向量指令占比很低，大部分还是标量——这叫假阳性，常见于循环体里有复杂控制流、编译器只向量化了一小部分。反过来，报告说“missed”也不一定真的没向量化，可能是外层循环没向量化但内层向量化了，或者编译器用了别的优化手段（比如循环展开加指令调度）达到了类似效果。

我的做法是：报告只作参考，最终以实际性能测试为准。用perf看指令数、用微基准测吞吐，比盯着报告文字靠谱。曾经有个循环报告说 missed，我差点去改代码，结果一测性能已经接近理论峰值，原来是编译器做了展开和调度，效果差不多。别被报告牵着鼻子走。

4.3 频率降频这个隐形杀手

AVX-512 有个著名的问题：使用 512 位宽指令时，CPU 会降低运行频率以控制功耗和散热，降频幅度可能达到 10% 到 20%。这意味着理论上 2 倍的向量宽度优势，可能被降频吃掉一大半，某些场景下甚至不如 AVX2。这个现象在服务器和工作站 CPU 上尤其明显。

所以选指令集不能只看理论宽度。我的经验是：先测 AVX2 版本的性能，再测 AVX-512 版本，如果后者没有明显优势（比如提升不到 20%），就保守用 AVX2，避免降频带来的不确定性。另外，AVX-512 的指令在某些 CPU 上吞吐不如预期，尤其是早期的实现，得实测。这个坑很隐蔽，因为代码逻辑完全正确，只是“没那么快”，不测根本发现不了。

4.4 别忽略编译器的“免费午餐”

最后说个反直觉的经验：很多时候你不需要手写 SIMD，只需要把代码写成编译器喜欢的样子。什么叫编译器喜欢的样子？循环边界清晰、没有指针别名、循环体内没有函数调用、数组访问是连续的、步长为 1。把这些条件满足，自动向量化往往就能生效，性能接近手写。

我做过对比：一个图像滤波的卷积核，手写 AVX2 intrinsic 版本比自动向量化版本快大约 15%，但代码量是后者的五倍，还得维护两套平台代码。对于迭代频繁的业务代码，这 15% 往往不值。所以我的建议顺序始终是：先写干净的、对编译器友好的标量代码，看报告确认向量化生效，测性能；只有确认瓶颈确实在向量化不足、且收益值得维护成本时，才上手 intrinsic。这个顺序能帮你避免大量无效优化。

提示：判断是否值得手写，算一笔账——手写版本相对自动向量化的额外加速，乘以这段代码在总耗时中的占比，如果小于维护成本带来的隐性开销，就别手写。

5. 跨平台与工程化：让向量代码活得久一点

单机跑通只是开始，向量代码真正难的是在多个平台、多个编译器、多次迭代中保持正确和可维护。这一节聊聊工程化层面的经验。

5.1 用条件编译隔离平台差异

一份代码要同时支持 x86 和 ARM，最直接的办法是条件编译。把平台相关的实现放在不同的文件或代码块里，用宏区分，上层调用统一的接口。关键是接口要设计得跟平台无关——参数用普通指针和长度，内部再决定用哪种向量实现。

#if defined(__AVX2__) // AVX2 实现 #elif defined(__ARM_NEON) // NEON 实现 #else // 标量回退 #endif

标量回退分支一定要有，而且要保证正确性。它是所有平台的兜底，也是测试的基准。我见过只写了向量路径、没写回退的代码，换到不支持的平台直接编译失败，或者更糟——编译通过但行为错误。回退路径不是可选项，是必需品。

5.2 运行时派发：一份二进制适配多种指令集

编译期条件编译的局限是：编译出来的二进制只针对一种指令集。如果想让同一份程序在老 CPU 上用 SSE、新 CPU 上用 AVX2，就得做运行时派发——程序启动时检测 CPU 支持的指令集，然后函数指针指向对应的实现。这个技术叫 CPU dispatch，GCC 的target_clones属性、Intel 的编译器、以及各种数学库都用这个套路。

实现上，通常把每个向量实现编译成独立函数，用__attribute__((target("avx2")))标注，主函数里根据 CPU 特性选择。这样一份二进制能覆盖多代硬件，代价是代码组织复杂一些、二进制体积大一点。对需要广泛分发的库来说，这个投入是值得的。

5.3 测试策略：向量代码怎么测才放心

向量代码的测试比普通代码更需要讲究。第一，边界长度必须覆盖：长度为 0、1、向量宽度减一、向量宽度、向量宽度加一、以及各种非整数倍长度，这些是最容易出错的点。第二，要和标量参考实现做逐元素对比，不能只比最终结果，否则中间某步错了可能被后续运算掩盖。第三，浮点比较要用容差，不能直接相等判断。

我的习惯是写一个标量参考版本，然后对随机生成的输入，逐元素对比向量版本和参考版本的输出，容差按数据量级设定。这个测试跑起来很快，能抓住绝大多数逻辑错误。另外，用不同优化级别（-O0 和 -O3）各跑一遍，有时候优化会暴露未定义行为，比如越界访问在 -O0 下碰巧没事，-O3 下就崩了。

6. 一个完整的落地示例：从标量到向量的改造过程

光讲理论不够，拿一个具体的小项目走一遍完整流程，把前面所有环节串起来。假设要实现一个图像亮度调整函数：对每个像素的 RGB 三个通道分别乘以一个系数，结果截断到 0 到 255。

6.1 标量版本与性能基线

先写最直白的标量版本，作为正确性基准和性能对照：

void adjust_brightness_scalar(uint8_t* data, int pixel_count, float factor) { for (int i = 0; i < pixel_count * 3; ++i) { float v = data[i] * factor; if (v > 255.0f) v = 255.0f; if (v < 0.0f) v = 0.0f; data[i] = (uint8_t)v; } }

这段代码逻辑清晰，但每个字节都要做一次浮点乘、两次比较、一次转换，循环体里还有分支。先测它的耗时作为基线，然后看编译器报告——大概率因为分支和类型转换，自动向量化不会生效，或者只部分生效。

6.2 向量化改造的关键决策

改造时要做几个决策。第一，数据类型：输入是 uint8，但计算用 float 更自然，需要做 uint8 到 float 的转换，向量指令里有对应的转换指令（如_mm256_cvtepi32_ps），但要注意 uint8 到 int32 的扩展需要先 unpack。第二，截断处理：标量版本用 if 比较，向量版本用min和max指令（_mm256_min_ps、_mm256_max_ps）实现无分支截断，正好避开分支向量化的难题。第三，尾部处理：像素总数乘以 3 之后不一定能被向量宽度整除，需要尾部标量循环。

这里有个容易忽略的点：RGB 三通道交错存储，向量化时如果按字节处理，一个向量里混着不同通道的数据，但乘的系数是同一个，所以没问题；如果不同通道系数不同（比如分别调 R、G、B），就得做数据重排（shuffle），复杂度上一个台阶。这个例子选统一系数，就是为了避开重排，聚焦在核心流程上。

6.3 实测数据与结论

在典型的中端 x86 平台上实测（数据规模 4MB，超出 L2 落在 L3），标量版本耗时约 8.2ms，AVX2 向量版本约 2.1ms，加速比接近 4 倍。理论上是 8 倍（256 位装 8 个 float），实际被内存带宽和类型转换开销吃掉一半。如果数据缩小到 256KB（落在 L2 内），加速比能到 6 倍以上，印证了前面说的“数据规模决定瓶颈层级”。

这个结果说明两件事：第一，即使是这么简单的逐元素操作，向量化收益也很可观；第二，别拿理论加速比当预期，实测才是准绳。改造过程中，我最初忘了处理尾部，导致像素数不是 8 的倍数时最后几个像素没被处理，测试用例一跑就露馅了——这也印证了边界测试的必要性。

7. 什么时候该收手：SIMD 的适用边界

技术讲了一堆，最后得说清楚它不适合什么场景，否则容易陷入“手里有锤子看什么都像钉子”的误区。

第一，数据规模太小的时候不值得。向量化的固定开销（装填、尾部处理、可能的运行时派发）在小数组上摊不开，短循环向量化后可能比标量还慢。经验阈值是：循环次数至少是向量宽度的好几倍，收益才稳定。

第二，内存带宽受限的场景收益有限。纯拷贝、简单赋值这类计算密度极低的操作，瓶颈在带宽，向量化只能减少指令数，减少不了数据搬运量。这时候该优化的是数据布局（比如结构体数组转数组结构体，提升缓存命中），而不是指令。

第三，分支密集、数据依赖复杂的代码不适合。图遍历、链表操作、状态机这类，向量化难度极大且收益不确定，不如从算法和数据结构层面优化。

第四，维护成本要算进去。手写 intrinsic 的代码可读性差、平台绑定强、调试困难，如果这段代码不是长期维护的热点，投入产出比可能为负。我个人的原则是：只有确认是热点、且自动向量化和封装库都搞不定时，才手写。

把这些边界想清楚，SIMD 才是一个理性的工具，而不是炫技的手段。实际项目里，我见过太多为了用 SIMD 而用 SIMD、结果代码复杂度暴涨性能却没提升的案例。性能优化永远是“先测量、再优化、再测量”的循环，SIMD 只是这个循环里的一件工具，用不用、怎么用，得让数据说话。