std::sort用par或par_unseq不提速是因硬件、数据、编译器和语义条件未满足；常见原因包括数据量小、迭代器非随机访问、未链接并发库、优化等级过低等。
直接用 std::execution::par 或 std::execution::par_unseq 调 std::sort，不等于自动变快——它只在满足硬件、数据、编译器和语义约束时才真正并行执行；多数“没加速”甚至变慢的情况，根本不是策略写错了，而是条件没凑齐。
为什么 std::sort(std::execution::par, ...) 经常不提速？
并行排序不是开关，而是带门槛的优化。常见失效场景包括：
- 数据量太小：低于 50,000 元素时，线程启动/同步开销远超收益；
std::vector<int> v(1000);上用par几乎必慢 - 迭代器不支持随机访问：传
std::list::begin()给std::sort会编译失败（标准禁止），但传std::forward_list迭代器可能静默退化为串行 - 编译器未启用并发支持：GCC 需链接
-pthread，Clang 需-lc++experimental（部分版本），MSVC 需启用 `/MD` 并链接并发运行时 - 优化等级过低：libstdc++ 和 libc++ 在
-O0下通常禁用并行路径；必须用-O2或更高
std::execution::par_unseq 排序比 par 快在哪？
par_unseq 不是“更激进的 par”，而是允许编译器做两层优化：线程级分块 + 单线程内 SIMD 向量化。但它对算法逻辑有硬性要求：
- 操作必须是纯函数：lambda 里不能调
std::cout、不能改全局变量、不能调用非 const 成员函数 - 比较器不能有副作用：比如
[&count]{ ++count; return a 是未定义行为 - 底层实现需支持：GCC 12+ / Clang 15+ 对
std::sort的par_unseq支持较完整；MSVC 2022 17.4+ 才开始稳定支持 - 实际效果依赖 CPU 指令集：AVX2 或 AVX-512 可显著提升向量化收益；老 CPU（如 Haswell 之前）可能只走多线程不向量化
如何验证并行排序真的起了作用？
没有 API 返回“当前用了几个线程”，但可通过三类可观测信号交叉确认：
立即学习“C++免费学习笔记（深入）”；
- CPU 利用率突增：用
htop -H（Linux）或任务管理器性能页（Windows），观察排序期间是否多个核心持续 >80% 占用 - 线程 ID 打点（仅调试）：
[](int& x) { std::cout << std::this_thread::get_id() << '\n'; }输出去重后数量 ≥2，说明分发成功（注意关掉输出缓冲或加std::flush） - 人工限核对比：Linux 下临时设
GOMP_THREADS=2，再跑一次；若耗时明显下降（比如从 120ms → 75ms），说明并行路径已生效 - 注意陷阱：某些 libstdc++ debug build 会静默降级为
seq；务必在 release 模式下验证
大规模排序的实用配置建议
真实业务中，别只盯着策略名，要结合数据特征和部署环境选型：
- 数据量 ≥ 10⁶ 且元素是 POD 类型（如
int、float）：优先试std::execution::par_unseq，配合-march=native编译 - 数据含自定义类型，且
operator<较重（如字符串比较）：用std::execution::par更稳妥，避免par_unseq因向量化边界问题导致额外分支开销 - 容器是
std::deque或std::vector<std::string>：仍可用par，但别用par_unseq—— 字符串内部指针跳转破坏向量化连续性 - 部署在容器环境（如 Kubernetes）且 CPU 配额受限：显式控制线程数比依赖默认调度更可靠，例如 GCC 下设
export GOMP_MAX_ACTIVE_LEVELS=1防止嵌套并行
最易被忽略的一点：std::sort 的并行版本不改变稳定性语义——它从来就不是稳定排序，无论用哪个策略。如果你需要稳定排序（如 std::stable_sort），目前标准库尚未提供对应的并行策略支持，强行套用会编译失败或静默退化。
