C++20 std::reduce：并行求和不是“开个线程就完事”

上周帮同事调一个图像处理模块，他用 std::accumulate 对千万级像素灰度值累加，单线程跑 800ms。我顺手改成 std::reduce 加 std::execution::par_unseq，耗时直接掉到 230ms——但第二天他发来截图：结果偶尔错 1~2 个单位。不是数据竞争，也不是浮点误差，而是他忽略了 reduce 对运算符的数学约束。

这很典型。很多人把 std::reduce 当成“并行版 accumulate”，改个函数名、加个策略就交差。可它真不是语法糖，而是一次对计算本质的重新协商。

std::reduce 出现在 C++17，C++20 补全了并行重载。它和 accumulate 最根本的区别在于：不保证执行顺序，也不要求运算符满足左结合性。accumulate 必须从左到右串行折叠，reduce 则把数据切成块，各算各的，最后合并。这就引出两个硬性前提：运算符必须可交换（a ⊕ b == b ⊕ a），且最好满足结合律（(a ⊕ b) ⊕ c == a ⊕ (b ⊕ c)）。

整数加法天然满足这两条，所以安全；浮点加法在数学上结合律不严格成立（1e20 + (1.0f + -1e20) ≠ (1e20 + 1.0f) + -1e20），但实践中多数编译器+硬件能给出合理结果；而减法、除法、字符串拼接这类非交换操作，直接用 reduce 就是埋雷。

实际写法很简单：

#include <numeric>
#include <execution>
#include <vector>

std::vector<int> data = /* ... */;
int sum = std::reduce(
    std::execution::par_unseq,  // 并行+向量化，最激进
    data.begin(), 
    data.end(),
    0,                          // 初始值（注意：这里不是“起点”，而是中性元）
    std::plus<>()              // 可选，加法默认存在
);

关键细节藏在三个地方：

• 初始值不是“起始偏移”：accumulate(v.begin(), v.end(), init) 是 init + v[0] + v[1] + ...；而 reduce(..., init) 是把 init 当作额外元素参与无序归约。若 init=0 且运算是加法，效果相同；但若 init=100，accumulate 结果恒比 reduce 多 100 —— 因为 reduce 的 init 被当作第零个数据参与并行分组计算，而非简单前置。

• 迭代器范围必须支持随机访问：reduce 需要将数据切片，std::list 或 std::forward_list 的迭代器直接编译失败。别指望它适配所有容器。

• par_unseq 不是银弹：它允许编译器自动向量化（如用 AVX 指令一次处理 8 个 int），但对小数组（比如 < 1000 元素）反而因调度开销变慢。实测表明，临界点通常在 4K~8K 元素之间，具体取决于 CPU 核心数和缓存行大小。建议对小数据集用 par，大数据集再升 par_unseq。

还有一个常被忽略的实用技巧：自定义归约类型可以绕过拷贝开销。比如处理 std::vector<std::string> 求总长度：

struct LengthSum {
    size_t value = 0;
    LengthSum() = default;
    LengthSum(const std::string& s) : value(s.size()) {}
    LengthSum operator+(const LengthSum& rhs) const { 
        return {value + rhs.value}; 
    }
    LengthSum& operator+=(const LengthSum& rhs) { 
        value += rhs.value; 
        return *this; 
    }
};

auto total_len = std::reduce(
    std::execution::par,
    strings.begin(), strings.end(),
    LengthSum{},  // 无构造函数调用开销
    [](const auto& a, const auto& b) { return a + b; }
);

这里没用 std::string::length() 反复调用，也没在每次合并时构造临时 size_t，LengthSum 把状态和操作内聚在一起，减少抽象损耗。

最后说句实在话：reduce 不是性能万能钥匙。如果你的“求和”逻辑里夹着 std::cout << "debug" 或者锁操作，那并行化只会让输出乱序、锁争用加剧。它真正发力的场景很明确：纯计算、无副作用、数据量大、运算符足够“干净”。

下次看到耗时长的累加循环，别急着换函数。先问自己：这个操作真的可交换吗？数据够不够多？初始值的意义我吃透了吗？—— 把这三个问题想清楚，reduce 才会从一个语法新特性，变成你工具箱里真正趁手的那把快刀。