std::execution::par 仅声明并行许可，实际是否加速取决于实现、数据规模、算法及环境；小数据或调试构建常更慢，需链接TBB等后端、确保无数据竞争、数据量>10⁴且单元素耗时>100ns才可能受益。
std::execution::par 不能自动加速任何算法
它只是告诉编译器“允许并行执行”，但是否真并行、能否提速，完全取决于底层实现、数据规模、算法本身和运行时环境。很多情况下加了 std::execution::par 反而更慢——尤其是小容器、简单操作或调试构建。
常见错误现象：std::sort(std::execution::par, v.begin(), v.end()) 在 v.size() == 100 时比串行还慢 2–3 倍；或者在未启用 TBB / libstdc++ 并行模式的环境下静默退化为串行（无警告、无报错）。
- 必须链接并行后端：GCC 需要
-ltbb或启用libstdc++的 parallel mode（-D_GLIBCXX_PARALLEL）；Clang + libc++ 目前基本不支持std::execution::par - 算法必须满足“无数据竞争”前提：所有迭代器操作不能读写同一内存位置，否则行为未定义（不是偶尔出错，是随时崩溃或静默错算）
- 开销敏感：并行启动成本约几百纳秒，建议只对
size() > 10^4且每元素处理耗时 > 100ns 的场景尝试
哪些 STL 算法真正支持并行且值得试
不是所有 std::algorithm 都实现了并行重载。目前只有部分算法在支持并行的 STL 实现中提供了 std::execution 重载，且效果差异极大。
使用场景：批量数值变换、大范围查找、排序、归约类操作。
立即学习“C++免费学习笔记（深入）”；
- 推荐优先试：
std::transform、std::for_each、std::sort、std::reduce、std::exclusive_scan - 慎用或无效：
std::find（早停逻辑破坏并行收益）、std::unique（依赖顺序）、std::nth_element（多数实现未提供并行重载） - 注意参数差异：比如
std::reduce并行版要求二元操作满足结合律和交换律，+可以，但-或自定义非交换函数不行
如何验证并行是否真的生效
不能靠“写了 par 就安心”。很多项目在 CI 或 Docker 容器里跑，线程数被限制为 1，std::execution::par 会自动降级为串行，你还以为自己开了并行。
常见错误现象：本地测得 3.2x 加速，上线后性能曲线完全没变化；或 valgrind 报 data race in std::for_each 却找不到源头。
- 检查实际并发度：
std::thread::hardware_concurrency()返回值是否 ≥ 2；在容器中可能返回 0，此时par必退化 - 加运行时断言：用
std::this_thread::get_id()在 lambda 里打日志，确认多个线程 ID 出现（仅调试用，别留生产） - 性能对比必须在同一构建配置下：关闭 ASan/UBSan（它们会禁用并行），用
-O2 -DNDEBUG，并绑定固定 CPU 核心（taskset -c 0-3 ./a.out）避免调度抖动
std::execution::par_unseq 是个危险选项
它不仅允许多线程，还允许编译器对循环内操作重排（vectorization + 多线程），但代价是彻底放弃顺序一致性语义。稍不注意就触发未定义行为。
使用场景：纯计算型、无副作用、无内存依赖的密集数值循环，比如图像像素点独立处理。
- 绝对禁止出现：
++counter、push_back、std::cout 、任何全局/静态变量访问 - 即使
std::vector<int> out(n)</int>，也必须确保每个线程只写自己负责的索引段，且不能依赖其他线程写入结果做判断 - Clang 15+ 对
par_unseq支持仍不完整；GCC 12 默认不启用向量化并行，需额外加-march=native
并行 ST L 最容易被忽略的点，是它从不解决数据布局问题。哪怕你用 par 跑 std::transform，如果输入是 std::vector<:string></:string>，缓存行失效和堆分配开销会吃掉所有并行收益——这时候换 std::vector<char></char> 拆包才是关键。
