C++17并行算法默认不生效，需显式指定执行策略且依赖编译器、标准库及运行时支持；libstdc++需-fopenmp/-pthread，libc++暂不支持par，MSVC仅支持par且需/Qpar选项。
并行算法在 C++17 中默认不生效，必须显式指定执行策略
你写 std::sort(std::execution::par, begin, end)，编译能过，但运行时大概率还是串行——因为多数标准库实现（如 libstdc++、libc++）默认不启用并行后端，或仅在特定平台（如 Linux + pthreads）且链接了额外库才可能触发。
实操建议：
- 确认编译器和标准库支持：GCC 9+ / Clang 7+ 是基本门槛，但 libc++ 目前（截至 clang 18）仍不支持
std::execution::par；libstdc++ 需要-fopenmp或-pthread并确保运行时有线程支持 - 用
std::execution::par_unseq替代par更现实：它允许向量化+乱序执行，部分场景下即使无多线程支持也能被优化（如 GCC 对transform的自动向量化） - 加个运行时检查：调用前打印
std::thread::hardware_concurrency()，返回 0 或 1 就别指望并行了
哪些 STL 算法真能并行，哪些只是“挂名”
不是所有标了 std::execution::par 参数的算法都实际并行。比如 std::find 在 libstdc++ 中是并行的，但 std::unique 和 std::partial_sort 目前（GCC 13）仍只接受策略参数，内部仍是串行实现。
目前较稳妥可用的并行算法（libstdc++ 实测有效）：
立即学习“C++免费学习笔记（深入）”；
-
std::sort、std::stable_sort：需随机访问迭代器，数据量 > 数万元素才明显受益 -
std::transform、std::for_each：无副作用时效果最好；有共享变量写入必须自己加锁或用std::atomic -
std::reduce、std::exclusive_scan：适合数值聚合，注意结合律要求（如自定义二元操作必须满足）
容易踩的坑：std::copy_if 并行版本不保证输出顺序，且无法预知输出容器大小——不能直接替代串行版填 vector，得先 resize 或用 back_inserter（但后者破坏并行性）。
性能不升反降？并行开销比你想的更重
小数据量（比如 x * 2），并行几乎一定更慢。线程启动、任务划分、同步、内存竞争的开销远超计算本身。
关键判断点：
- 每个元素处理耗时最好 > 100ns，否则别上
par - 避免 false sharing：多个线程写相邻内存（如数组连续位置），会因缓存行争抢严重拖慢；可改用结构体数组（SoA）或 padding
- 不要在循环内反复调用并行算法：比如对每个 vector 调一次
std::transform，不如把所有 vector 合并后一次性处理
一个典型反例：std::vector<:string></:string> 上跑 std::for_each(par, ..., [](auto& s) { s.clear(); }) —— string 内部堆分配 + 引用计数操作导致大量锁竞争，并行反而比串行慢 3 倍以上。
Windows MSVC 下的特殊限制
MSVC（Visual Studio 2019/2022）对 C++17 并行算法的支持最完整，但有个硬伤：只支持 std::execution::par，不支持 par_unseq（报错 “unsequenced policy not supported”）。
实操要点：
- 必须开启 `/Qpar` 编译选项（不是 `/O2` 自带的），否则所有并行策略退化为串行
- 调试模式下（/RTC、/MDd）并行常被禁用，务必在 Release 模式验证效果
- 异常传播行为不同：并行算法中某线程抛异常，可能终止整个算法，且异常类型可能被截断（比如只传 std::exception 的基类）
跨平台代码如果同时适配 GCC/Clang/MSVC，建议用宏包裹执行策略：#ifdef _MSC_VER auto policy = std::execution::par; #else auto policy = std::execution::par_unseq; #endif，再传给算法。
真正麻烦的从来不是怎么写那行 std::execution::par，而是确认你的数据规模、内存布局、编译配置和运行时环境有没有悄悄把它变成一句空话。
