3 ms·
The first one too? Isn't that the map-reduce fork-join golden example of multiprocessing?
by rzzzt 3mo ago
The first one too? Isn't that the map-reduce fork-join golden example of multiprocessing?
- cwzwarich 3mo ago`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 3mo agoC++ has std::reduce for that, which is std::accumulate except it's defined to operate without any specific ordering.
- rzzzt 3mo agoThanks everyone, my C++ knowledge has been greatly expanded today.
- Joker_vD 3mo agoAnd 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.
- tcfhgj 3mo ago1) 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)
- CITIZENDOT 3mo agostd::accumulate is sequential and guarantes in order traversal. std::reduce is parallel version of it