hpc · high

Parallel STL (std::execution)

C++17 parallel algorithms let you keep the STL but pick an execution policy: std::execution::seq (sequential), par (multi-threaded), or par_unseq (multi-threaded and vectorized). std::reduce/transform_reduce replace accumulate because they may re-associate the combine to parallelize — requiring an associative, commutative operation and, for floating-point, accepting tiny ordering differences. par_unseq additionally forbids locks, allocation, and shared-state access in the element function, since calls may interleave to fill SIMD lanes. Two pitfalls: an exception escaping a parallel algorithm calls std::terminate, and parallelism only pays off above a problem-size threshold. libstdc++ builds these on Intel TBB, so link with -ltbb.

The code

#include <execution>   // C++17 parallel algorithms
#include <numeric>
#include <algorithm>

std::sort(std::execution::par, v.begin(), v.end());           // multi-threaded sort
auto s = std::reduce(std::execution::par, v.begin(), v.end());// parallel sum
std::transform(std::execution::par_unseq, in.begin(), in.end(),
               out.begin(), f);                               // threads + SIMD

// par       : multiple threads
// par_unseq : threads AND vectorization (no inter-element ordering)
// link with TBB:  g++ -O2 -std=c++20 -ltbb

What this lesson walks through

1. 01Parallelism as an execution policy
2. 02reduce vs accumulate — why the new name
3. 03par_unseq: threads AND SIMD
4. 04The catch: exceptions and overhead

C++17 added execution policies: pass std::execution::par as the first argument to a standard algorithm and it runs across threads — same algorithm, same result, no thread code. std::reduce, std::sort, std::transform, std::for_each and more all take a policy.