Addendum 2: Benchmarking with different partitions

Construct hashmap of eighteen mathematical ops, per element

How do Brokvolli's multi-threaded transduce benchmarks vary with different partition sizes?

Observations: Partitions must be significantly smaller than the input vector to realize a performance improvement.

See also:

• Main benchmarks
• Addendum 1: Increased computations per element
• Addendum 3: Performance scaling with processors

Benchmarks defined here, similar to before. For exploring the affects of partition size, we'll consider only multi-threaded transduce. We'll test vectors increasing in length from one element to one-hundred-thousand elements, by powers of ten. For each element, a pre-generated random floating point number, we'll construct a hashmap of eighteen mathematical operations on that number (trig ops, logarithms, etc.) that the JVM compiler oughtn't be able to optimize. To amplify the computation requirements, we'll construct variations of that hashmap five times for each element. We'll use the Criterium benchmarking library to measure the execution times of sixty repetitions of each condition. Benchmarks were run on three explicitly-pinned cores of my antique desktop computer.

Overall, we observe that the execution times increase with increasing vector lengths. The results are relatively indistinguishable when the vector contains ten or fewer elements. When the partition is exactly the vector's length, the transduction runs exactly as fast as single-threaded transduce, as expected. Once the vector length exceeds the partition size, we can see performance benefits to the multi-threading. When the vector length is one-hundred elements or more and when the partition size results in multiple threads, the processing time is roughly twice as fast.