加 std::execution::par 未提速是因为数据量过小、编译器不支持或运行时环境限制，导致未触发并行分支，CPU 单核满载而实际仍串行执行。
直接结论：用 std::execution::par 或 std::execution::par_unseq 传给 std::sort，但必须满足数据规模、编译器和运行时三重条件，否则根本不会多核并行。
为什么加了 std::execution::par 却没提速？
常见现象是代码编译通过、运行无错，但 CPU 使用率单核打满，std::sort 表现和串行一样。根本原因不是写法错，而是底层没触发并行分支：
- 数据量太小（通常 std::sort，避免线程创建开销反超收益
- 编译器未启用并行支持：GCC 需
-fopenmp或链接libstdc++fs；Clang 需-D_LIBCPP_ENABLE_PARALLEL_ALGORITHMS+-lc++experimental - 运行时线程池未就绪：某些 libc++ 实现依赖
std::thread可用性，若程序启动后从未创建过线程，首次par调用可能延迟初始化或静默退化 - 容器迭代器不满足
RandomAccessIterator要求（如std::list::iterator）——std::sort直接编译失败，不是慢，是压根不能用
std::execution::par 和 std::execution::par_unseq 怎么选？
两者都启用多线程，但行为差异直接影响结果正确性和性能边界：
-
std::execution::par：保证各线程内操作顺序，允许跨线程乱序调度，适合含副作用的比较函数（如带日志、计数器），但 SIMD 向量化不强制启用 -
std::execution::par_unseq：允许线程内指令重排 + SIMD 向量化，性能通常更高（实测快 20–30%），但要求比较函数绝对无副作用（不能读写全局变量、不能调用非 const 成员函数） - 若比较函数用
std::less<int>()这类纯函数，优先选par_unseq；若需调试追踪，用par更稳妥
实际能跑起来的最小完整示例
以下代码在 GCC 12+ / Clang 14+ 下可稳定触发多核（注意编译参数）：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
#include <vector>
#include <algorithm>
#include <execution>
#include <chrono>
int main() {
std::vector<int> data(2'000'000); // 必须 ≥ 1e6 才大概率并行
// ... 填充随机数据
auto start = std::chrono::high_resolution_clock::now();
std::sort(std::execution::par_unseq, data.begin(), data.end());
auto end = std::chrono::high_resolution_clock::now();
}
关键点：
- 数据量写死为 200 万，低于 50 万基本看不到并行效果
- 必须包含
<execution>头文件，否则std::execution未定义 - Clang 用户需确认是否链接了实验性并行库（
-lc++experimental），否则链接时报undefined reference to __gnu_parallel::sort
容易被忽略的硬件与内存影响
即使代码、编译器、数据量全对，真实加速比仍受制于两个隐蔽因素：
- NUMA 架构下，若数据分配在 Node 0，而线程被调度到 Node 1 执行，跨节点内存访问延迟飙升——建议用
numactl --cpunodebind=0 --membind=0 ./a.out绑定 - 默认
std::vector分配的内存不保证缓存行对齐，高并发读写易引发伪共享（False Sharing）；对极致场景，应手动用aligned_alloc分配并用std::execution::par_unseq配合 - 排序过程本身是内存带宽密集型任务，8 核 CPU 在 DDR4-3200 上常因内存吞吐瓶颈卡在 4–6 倍加速比，而非理论 8 倍
真正决定能不能多核跑起来的，从来不是那行 std::execution::par，而是数据量够不够、编译器链得对不对、内存有没有被悄悄拖后腿。
