std::execution::par_unseq 是大规模 std::sort 最有效的提速策略，但需满足数据量大、无副作用、编译器与标准库支持三重条件；盲目使用 par 或 par_unseq 反而更慢。
直接上结论：std::execution::par_unseq 是目前对大规模 std::sort 提速最有效的策略，但必须满足数据量大、无副作用、编译器与标准库支持三重条件；盲目套用 par 或 par_unseq 反而更慢。
为什么 std::sort(std::execution::par, ...) 经常没提速？
这不是 bug，是并行开销压倒收益的典型表现。串行 std::sort 本身已高度优化（introsort），并行化需额外做分块、归并、线程同步等操作——只有当这些开销被计算收益覆盖时，才真正变快。
- 数据量太小：小于 ~50 万元素时，
par常比seq慢 10%–30%，尤其在-O2下更明显 - 迭代器不支持随机访问：
std::list::begin()传给std::sort+par会编译失败（SFINAE 拒绝），std::deque则可能降级为低效实现 - 编译器未启用线程支持：GCC/Clang 需链接
-pthread，MSVC 需定义_ENABLE_ATOMIC_ALIGNMENT_FIX并启用并发运行时 - 标准库实现限制：libstdc++（GCC）在 debug 模式下静默禁用所有并行策略；libc++（Clang）对
par_unseq的 SIMD 生成依赖-mavx2等显式指令集开关
std::execution::par_unseq 真正起效的硬性条件
par_unseq 不是“更强的 par”，它是另一类执行模型：允许编译器在单个线程内做向量化 + 跨线程做并行，因此对算法逻辑约束极严。
- 操作必须是纯函数：lambda 中不能调用
std::cout、printf、std::mutex::lock()，也不能修改任何外部变量（包括通过[&]捕获的int counter） - 比较器不能有可变状态：例如
struct CounterComp { mutable int calls = 0; bool operator()(...) const { ++calls; return ...; } };→ 未定义行为 - 底层容器内存必须连续且对齐：
std::vector没问题，std::aligned_alloc分配的缓冲区需确保 32 字节对齐（AVX2）或 64 字节（AVX-512）才能触发向量化分支 - 编译选项必须匹配：Clang 需
-O2 -march=native -stdlib=libc++；GCC 需-O3 -mavx2 -fopenmp（libstdc++ 并行后端依赖 OpenMP 运行时）
如何验证并行是否真的跑起来了？
没有 API 能返回“当前用了几个线程”，但可通过三类可观测信号交叉确认：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- CPU 使用率：用
htop（Linux）或任务管理器（Windows）观察是否多个核心持续 >80% 占用；注意排除其他进程干扰 - 线程 ID 打点（仅调试）：
[](int& x) { std::cout → 若输出中出现 2+ 个不同 ID，说明多线程已启动（但注意 <code>std::cout本身会序列化，仅作辅助判断） - 强制限核对比：Linux 下执行
GOMP_THREADS=1 ./a.out与GOMP_THREADS=8 ./a.out，若耗时几乎不变，说明根本未走并行路径（常见于 libstdc++ 未链接-fopenmp）
特别注意：std::sort 在 par_unseq 下的归并阶段仍可能部分串行，因此即使多核跑满，加速比也难达线性——实测 1000 万 int 在 8 核 CPU 上，par_unseq 通常比 seq 快 3.2–4.1 倍，而非 8 倍。
实际项目中该选哪个策略？
别凭感觉，按场景选：
- 排序百万级以上整数/浮点数，且无自定义比较器 → 无条件用
std::execution::par_unseq，配合-O3 -march=native - 排序含自定义比较逻辑（如字符串 locale 比较）、或数据量在 10 万–50 万之间 → 选
std::execution::par，它不尝试向量化，稳定性更高 - 调试期、小数据集、或需断点逐行跟踪 → 回退到
std::execution::seq，避免并发干扰调试流 - 明确要 GPU 加速（C++26 实验性支持）→ 需手动构造
std::execution::on(ctx)上下文，但当前主流编译器（GCC 14 / Clang 18）尚未落地完整实现，不建议生产环境依赖
最容易被忽略的一点：并行策略只影响算法内部执行方式，不改变接口语义——std::sort 仍是就地排序、稳定性和异常安全保证降级（par_unseq 下为弱异常安全），这点在封装通用工具函数时必须显式文档化。
