Addendum 3: Benchmarking with different processor counts

This test performs the following mathematical operations per element: cube root, ceiling, cosine, cubing, decrement, natural exponentiation, exponentiation, floor, identity, increment, logarithm, natural logarithm, multiply by π, negation, round, sine, square-root, and tangent. For each element, that group of operations was performed five times on jittered values of the elements (i.e., (* 18 5) => 90 operations per vector element). The "version" labels in the chart legend correspond to the taskset --cpu-list directives: 0-3 pins the benchmark to processors zero through three (i.e., four processors), 0-31 pins the benchmark to processors zero through thirty-one (i.e., thirty-two processors), etc.

When the sample vector contains one hundred or fewer elements, the 1-processor benchmarks (a proxy for single-threaded transduce) runs slightly faster (blue circles), likely due to the minimal overhead of managing the threads running on a single CPU. Above one thousand elements, the multi-processor (i.e., >1 CPU) tests demonstrate a speedup. For vectors containing ten- or one-hundred-thousand elements, the evaluation times decrease with increasing numbers of processors/threads. (Note that the logarithmic scale may disguise the magnitude of the speedups; select the "Show details" button to see the measured times).

Here's a rough summary of the speedups for one-hundred-thousand-element vectors.

For this synthetic workload, recruiting up to thirty-two processors increased multi-threaded transduce's ability roughly proportionately. Two CPUs could chew through same partitions 1.6× as fast as one CPU; four CPUs could do the job 3.7× as fast as one CPU, etc. In general, the speedups are two-thirds to three-quarters times the number of CPUs. In other words, 8 CPUs give us about a 6× speedup, while 16 CPUs give us about an 11× speedup.

An anomalous limit emerges somewhere between thirty-two (gold circles) and sixty-four (magenta diamonds) CPUs where the performance does not improve proportionally. Investigating this phenomenon is beyond the scope of this report.

(fn [n] (multi/transduce partition-at concatv xform-1 tconj (vecs n)))