Safety and Performance Considerations

In general, reducers do not require locks to provide repeatable results across parallel runs. The results are the same as for a serial execution.

When developing your program, be aware of the following safety and performance considerations.

Safety

To get strictly deterministic results, all operations (update and merge) that modify the value of a reducer must be associative.

The reducers defined in the reducer library provide operators that are associative. In general, if you only use these operators to access the reducer, you will get deterministic, serial semantics. It is possible to use reducers with operations that are not associative, either by writing your own reducer with non-associative operations, or by accessing and updating the underlying value of any reducer with unsafe operations.

Determinism

When reducers are instantiated with floating-point types, the operations are not strictly associative. Specifically, the order of operations can generate different results when the exponents of the values differ. This can lead to results that vary based on the order in which the strands execute. For some programs, these differences are tolerable, but be aware that you may not see exactly repeatable results between program runs.

Performance

When used judiciously, reducers can incur little or no runtime performance cost. However, the following situations may have significant overhead. The overhead is proportional to the number of steals that occur.

If you create a large number of reducers (for example, an array or vector of reducers) be aware that there is an overhead at steal and reduce that is proportional to the number of reducers in the program.

If you define reducers with a large amount of state, it may be expensive to create identity values when the reducers are referenced after a steal.

If the merge operation is expensive, remember that a merge occurs at every sync that follows a successful steal.