C++17 中的执行策略（Execution Policy）：并行与矢量化编程的新范式

C++17 引入了 std::execution 命名空间及一系列执行策略（execution policies），为标准算法库注入了并行化与潜在向量化能力。这一特性并非简单地“加速已有代码”，而是以类型安全、零开销抽象的方式，将执行语义显式分离于算法逻辑之外，标志着 C++ 在高性能计算与现代硬件适配方面迈出关键一步。

在 C++17 之前，std::sort、std::transform、std::reduce 等算法仅提供串行语义——无论数据规模多大，它们总在单一线程中顺序执行。开发者若需并行处理，往往需手动拆分任务、管理线程池或依赖第三方库（如 Intel TBB），不仅增加复杂度，也破坏了 STL 算法一贯的简洁性与可组合性。执行策略的引入，首次使“如何执行”成为可参数化的正交维度：同一算法调用，仅通过更换策略对象，即可在串行、并行、并行向量化等模式间切换。

C++17 定义了三种标准执行策略：

• std::execution::seq：严格串行执行，无数据竞争，行为与 C++14 及更早版本完全一致；
• std::execution::par：允许并行执行（通常使用线程池），要求算法操作为无副作用且可随意重排；
• std::execution::par_unseq：允许并行 且 向量化（unsequenced），即编译器可在单个线程内自动展开循环、使用 SIMD 指令，甚至重排内存访问——这是对底层硬件最激进的优化授权。

值得注意的是，所有策略均为类型而非值，其传递不产生运行时代价；策略对象本身是空类型（empty type），仅用于模板参数推导与重载决议。这意味着策略选择完全在编译期完成，无虚函数调用、无分支预测惩罚。

以下示例展示了 std::transform 在不同策略下的使用差异：

#include <algorithm>
#include <execution>
#include <vector>
#include <chrono>

std::vector<double> input(10'000'000, 1.5);
std::vector<double> output(input.size());

// 串行执行：确定性、易调试、无额外依赖
auto start = std::chrono::high_resolution_clock::now();
std::transform(std::execution::seq,
               input.begin(), input.end(),
               output.begin(),
               [](double x) { return std::sin(x) * std::cos(x); });
auto seq_dur = std::chrono::high_resolution_clock::now() - start;

// 并行执行：利用多核，但需确保 lambda 无共享状态修改
start = std::chrono::high_resolution_clock::now();
std::transform(std::execution::par,
               input.begin(), input.end(),
               output.begin(),
               [](double x) { return std::sin(x) * std::cos(x); });
auto par_dur = std::chrono::high_resolution_clock::now() - start;

// 并行+向量化：进一步释放单核潜力，要求操作满足更强约束
start = std::chrono::high_resolution_clock::now();
std::transform(std::execution::par_unseq,
               input.begin(), input.end(),
               output.begin(),
               [](double x) { return std::sin(x) * std::cos(x); });
auto par_unseq_dur = std::chrono::high_resolution_clock::now() - start;

上述代码中，三个调用仅策略字面量不同，语义接口完全一致。但背后执行模型截然不同：par_unseq 要求 lambda 不仅无副作用，还不得依赖浮点运算的严格顺序（因 SIMD 打乱求值序可能导致细微精度差异），亦不可调用非 constexpr 或非 noexcept 的非内联函数——这些限制由标准明确列出，是实现正确性的必要条件。

执行策略的适用性取决于算法本身。C++17 标准明确支持策略的算法包括：adjacent_difference、exclusive_scan、for_each、inclusive_scan、reduce、transform_reduce、transform、sort、stable_sort、partial_sort、partial_sort_copy、nth_element 等共 15 个。并非所有算法都支持全部策略：例如 std::find 仅支持 seq 和 par（因 par_unseq 下首个匹配位置无法保证线性搜索序），而 std::sort 对 par_unseq 的支持则依赖具体实现是否能安全地向量化比较与交换逻辑。

实际应用中，策略选择需权衡确定性、性能与可移植性。seq 是默认安全起点；par 在数据量大、操作计算密集（如数学函数、图像像素处理）时收益显著；par_unseq 则适合高度规则的数值计算（如向量加法、矩阵乘法内积），但需充分验证结果一致性。此外，运行时环境亦影响效果：线程数受 std::thread::hardware_concurrency() 限制；某些平台可能未启用 SIMD 支持；调试器可能无法逐行跟踪 par_unseq 内部展开。

一个易被忽视的关键点是异常处理语义。当 par 或 par_unseq 策略下某次操作抛出异常，标准规定：第一个异常将被捕获并重新抛出，其余并发操作会被取消。这避免了多异常同时传播的不确定性，但也意味着部分元素可能未被处理。因此，对强异常安全有要求的场景，应优先评估 seq 或设计容错机制。

最后需强调：执行策略不是银弹。它无法自动优化内存带宽瓶颈、缓存不友好访问或粗粒度同步。若算法本身存在数据依赖链（如前缀和 inclusive_scan 的固有依赖），par 策略仍需采用分治归约等技巧，而非简单并行循环。开发者仍需理解问题本质，策略只是将底层优化责任更清晰地委托给标准库实现者。

综上所述，C++17 的执行策略是一次深思熟虑的演进——它没有颠覆 STL 的哲学，而是以极小的语法增量，赋予算法库面向异构硬件的表达力。它不强制并行，但为并行提供标准化路径；不限制优化，却以类型系统约束其安全边界。对于追求性能又不愿牺牲可维护性的 C++ 工程师而言，掌握 std::execution 不仅是技术升级，更是思维方式的迭代：从“写代码”转向“声明意图”，让编译器与运行时共同承担起贴近硬件的优化责任。随着 C++20/23 对更多算法与策略（如 unseq 的细化、任务块支持）的持续增强，这一范式正日益成为现代 C++ 高性能开发的基石。