Control.Parallel.Strategies expresses deterministic parallel evaluation without changing an algorithm. A Strategy describes how a value should be evaluated; helpers apply that strategy across lists and other Traversable containers. Use it when a pure, expensive mapping—such as pixel processing—has independent pieces of work. section 13.4.3 section 13.5
`using` and `withStrategy` attach a strategy to a result. For a list, `evalList rpar` requests parallel evaluation of each element. `rpar` creates a spark, but a spark is only potential parallel work: it can fizzle if demanded too soon, be a dud if already evaluated, or overflow the spark pool when too many are created. section 13.4.3
Parallel list mapping
```haskell import Control.Parallel.Strategies map (^ 100) [1 .. 1000] `using` evalList rpar -- Equivalent spelling withStrategy (evalList rpar) $ map (^ 100) [1 .. 1000] ``` For a `Vector`, use `evalTraversable rpar`, since `Vector` has a `Traversable` instance. This direct approach may create one spark per pixel, which can overwhelm the spark pool. section 13.4.3
Prefer chunking when a collection is large. `parListChunk size rseq` evaluates chunks in parallel while evaluating elements within each chunk sequentially. A `Vector` strategy can convert to a list, apply that chunked strategy, and rebuild the vector; applying it with `withStrategy` turns a pixel mapping into a bounded number of larger parallel tasks. section 13.4.3 section 13.5
Figure 13.5 Haskell execution contexts and spark pools
Spark pools belong to Haskell execution contexts; their capacity helps explain why excessive fine-grained sparks reduce effective parallelism. section 13.4.3
