[rzzzt]

The first one too? Isn't that the map-reduce fork-join golden example of multiprocessing?

[cwzwarich]

`std::accumulate` is defined to have sequential semantics, so the analysis required to make it parallel is probably not that different than starting from the loop version. I guess you could have an alternate `accumulate_associative` that uses the same interface but assumes the reduction is associative and has unspecified evaluation order?

[mpyne]

C++ has std::reduce for that, which is std::accumulate except it's defined to operate without any specific ordering.

[rzzzt]

Thanks everyone, my C++ knowledge has been greatly expanded today.

[Joker_vD]

And now you should probably also stop and consider whether adding elements one-by-one as opposed to recursively adding together sums of smaller subarrays has better or worse numerical behaviour in regards to e.g. rounding and stability.

[CITIZENDOT]

std::accumulate is sequential and guarantes in order traversal. std::reduce is parallel version of it

[tcfhgj]

1) afaik accumulate cannot be parallelized

2) the map part is included in the accumulate lambda, so the map part cannot be parallelized either -> you'd have to split it out into a transform step (iirc)