C++ 并行算法的“油门”与“刹车”：execution_policy 实战手记

写过 std::sort，也调过 std::transform，但你有没有试过——让它们在多核上真正跑起来，而不是只在单线程里默默加班？
C++17 引入的 execution_policy 不是语法糖，也不是给简历镀金的装饰项。它是一套可预测、可调试、可权衡的并行控制机制——就像给算法装上了手动挡：你决定何时加速、何时降档、何时干脆挂空挡。

先说个真实场景：上周帮同事优化一个日志解析模块，原始代码用 std::for_each 遍历百万条记录做正则提取，耗时 2.3 秒。加了 std::execution::par_unseq 后掉到 0.6 秒。但第二天 QA 报了个偶发崩溃——原因不是数据竞争，而是他误把 std::vector::push_back 放进了并行 transform 的 lambda 里。policy 不负责兜底，它只负责执行你的指令；它不判断你写的逻辑是否线程安全，只问：你确定要这么干吗？

C++ 标准目前定义了三种策略：

• std::execution::seq：强制串行。别被名字骗了——它不是“默认选项”，而是明确放弃并行的声明。适用于调试、或对顺序敏感的副作用操作（比如按索引写入全局计数器）。
• std::execution::par：任务级并行。标准库用线程池或类似机制分发子任务，每个子任务内部仍按顺序执行。适合计算密集、无共享写入、迭代器可随机访问的场景（如 vector 上的 reduce）。
• std::execution::par_unseq：并行 + 向量化。这是最激进的选项——不仅跨核，还允许编译器重排、向量化、甚至在一个线程内用 SIMD 指令批量处理。但它要求 lambda 绝对无副作用，且不能依赖迭代顺序（比如 i 和 i+1 的值不能互相影响）。

关键不是“哪个更快”，而是哪个更可控。par_unseq 在 std::transform 上可能快 3 倍，但在 std::adjacent_find 上直接编译失败——因为该算法语义依赖相邻性，而 par_unseq 允许打乱执行顺序。这不是 bug，是设计契约。

实际选型时，我习惯三步判断：
第一步，看数据结构：vector、array、原生指针？可以；list、forward_list？绕道。par 和 par_unseq 要求随机访问迭代器，否则编译不过。
第二步，看操作性质：纯函数式变换（sqrt, toupper）、无状态规约（std::reduce 求和）？放心上 par_unseq；涉及 std::cout <<、static int counter++、或修改外部容器？退回 seq，或手动拆分 + std::thread 更稳妥。
第三步，看硬件与负载：笔记本双核轻负载，par 可能比 par_unseq 更稳；服务器 64 核跑科学计算，par_unseq 才是常态。但注意：并行开销真实存在——小数据量（< 10k 元素）用 par 反而更慢，线程创建/同步成本盖过了计算收益。

有个容易被忽略的细节：execution_policy 是非传递性的。比如你写了 std::transform(par, begin, end, out, f)，但 f 内部又调用了另一个带 policy 的算法？那层 policy 不会自动继承。它只作用于当前这一层调用。这意味着——并行边界由你亲手划定，不会意外溢出。

调试并行算法，别只盯着 data race。我常用两个低成本手段：

• 编译时加 -D_GLIBCXX_PARALLEL（GCC）或启用 libc++ 的并行模式，让 seq 版本也走并行后端，快速验证逻辑正确性；
• 在 lambda 里加 assert(std::this_thread::get_id() != main_tid)，确认确实分发了——有时候你以为并行了，其实调度器悄悄退化成串行（比如数据太小，或系统忙不过来）。

最后说个反直觉但实用的经验：不要迷信 par_unseq 是终极答案。我们团队做过对比测试，在图像像素处理中，par_unseq 对 uint8_t 数组做伽马校正，速度只比 par 快 12%，但调试难度翻倍——SIMD 对齐、内存访问模式、编译器版本差异全冒出来了。最终上线版用的是 par + 手动 4 路分块，稳定、易复现、CPU 利用率曲线平滑。

execution_policy 的价值，不在“让代码变快”，而在把并行决策权从编译器/库手里，交还给你。它不承诺性能，但承诺可解释性：当你看到 std::sort(par, ...)，你就知道这行代码的延迟、吞吐、资源占用，和它的语义一样清晰。

下次再面对一个慢算法，别急着换库或加机器。先问自己一句：它真的需要并行吗？如果需要，我准备好承担并行带来的责任了吗？
policy 不是魔法开关，而是方向盘——握紧它，车才不会跑偏。