std::execution::par对std::sort或std::transform无加速甚至更慢，是因为它仅在数据量大（≥50万）、硬件多核、编译器启用并发支持（如GCC需-fopenmp）、STL实现支持（libc++至今不支持）且优化等级足够（-O2以上）时才生效；否则静默退化为串行。
直接加 std::execution::par 到 std::sort 或 std::transform 上，大概率不会变快，甚至更慢或崩溃——这不是写法错，是并行策略本身不自动“加速”，它只在数据、硬件、编译器、算法四者严丝合缝时才生效。
为什么 std::execution::par 调用后毫无加速？
常见现象：CPU 单核 100%、耗时没降、htop 看不到多线程活动。根本原因不是代码有 bug，而是策略被静默降级为串行。
- libstdc++（GCC）默认不启用并行后端，必须显式链接
-fopenmp或-D_GLIBCXX_PARALLEL，否则par直接退化为seq - libc++（Clang）截至 2026 年 4 月仍基本不支持
std::execution::par，传了也无效 - MSVC 需开启
/qpar且仅部分算法（如transform）真正启用，并行sort在 17.4+ 才较稳定 - Debug 构建（
-O0）下，所有主流 STL 实现都会禁用并行路径；必须用-O2或更高且定义NDEBUG -
std::thread::hardware_concurrency()返回 0 或 1（如容器环境、CI 机器限制），par必然不触发
哪些算法真能并行且相对安全？
别信“支持列表”，要看实际实现稳定性。目前经过 libstdc++ 12+、MSVC 2022 17.4+ 和 libc++ 15+ 充分验证的只有这几个：
-
std::transform：纯函数式映射，par_unseq效果最明显（SIMD + 多线程） -
std::reduce：要求二元操作满足结合律（+可以，-不行），初始值类型必须匹配 -
std::for_each：仅当 lambda 无副作用（不改全局、不调非 const 成员、不push_back同一容器）才安全 -
std::inclusive_scan/std::exclusive_scan：前缀和类操作，par可用，par_unseq尚未广泛验证
std::sort 和 std::stable_sort 虽语法支持，但行为高度依赖实现：GCC 的并行排序仍不如 TBB；MSVC 更成熟，但小数据（v.size() < 500000）必慢；par_unseq 对 sort 是危险选项——它破坏顺序语义，而排序内部有强依赖，极易触发未定义行为。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
怎么写才能让 par_unseq 真正起效？
par_unseq 不是 “更强的 par”，它是向量化 + 多线程混合模型，对代码约束极严。
- lambda 必须是纯函数：不能捕获局部栈地址（
[&x]错，[x]可）、不能调std::cout、不能修改任何外部状态 - 底层内存需对齐：
std::vector没问题；若用aligned_alloc，AVX2 要求 32 字节对齐，AVX-512 要求 64 字节 - 编译选项必须匹配：Clang 需
-O2 -march=native；GCC 需-O3 -mavx2 -fopenmp - 典型安全用法：
std::transform(std::execution::par_unseq, a.begin(), a.end(), b.begin(), [](int x) { return x * x + 1; }); - 典型崩溃用法：
std::for_each(std::execution::par_unseq, v.begin(), v.end(), [&sum](int x) { sum += x; });——sum是共享可变状态，无同步即未定义行为
如何确认并行真的跑起来了？
没有 API 能返回“用了几个线程”，只能靠三类可观测信号交叉验证：
- CPU 使用率：用
htop -H（Linux）或任务管理器性能页（Windows），观察排序/变换期间是否多个核心持续 >80% 占用 - 线程 ID 打点（仅调试）：
std::for_each(std::execution::par, v.begin(), v.end(), [](int&) { std::cout << std::this_thread::get_id() << std::endl; });，输出去重后数量 ≥2 才算分发成功（注意加std::flush防缓冲干扰） - 人工限核对比：Linux 下
GOMP_THREADS=2 ./a.out，若耗时明显下降（如 120ms → 75ms），说明并行路径已通
最容易被忽略的是：并行策略不解决数据竞争，它只负责分发。你写的 lambda 是否线程安全，完全由你自己保证——std::execution 不加锁、不校验、不兜底。
