~ /phase-2 /results
Phase II · Results

Slower first, then 5.79× faster.

The official benchmark results for the Java multithreading experiment, and what they mean. Multithreading helped, but only once there were enough threads to outweigh their overhead.

Apple M2 · 8 coresOpenJDK 25 LTS12 runs / configArray: 1,000,000 ints

Main results#

Threads Avg execution time (ms) Speedup % Improvement
1 3.754 1.00 0.00
2 4.335 0.87 -15.48
4 3.111 1.21 17.14
6 0.698 5.38 81.41
8 0.649 5.79 82.72
avg execution time · ms
1 thread
3.754
2 threads
4.335
4 threads
3.111
6 threads
0.698
8 threads
0.649
speedup · T(1) / T(n) measuredideal

What the table shows#

Best runtime#

8 threads produced the fastest average execution time: 0.649 ms.

Scaling pattern#

The improvement was not gradual. Most of the drop happened between 4 and 6 threads.

Overhead at low counts#

2 threads were slower than 1. Managing the threads cost more than it saved at that configuration.

Practical sweet spot#

6 and 8 threads both performed very well, so useful scaling starts at the higher thread counts.

Graphs#

The three graphs prepared for the report, based on the same table.

Execution time vs number of threads

Speedup vs number of threads

Percentage improvement vs number of threads

  • Execution time. Runtime did not fall smoothly from 1 to 8 threads. It rose at 2, improved slightly at 4, and only dropped sharply at 6 and 8.
  • Speedup. A value below 1.0 means the parallel version is worse than the baseline, which is what happened at 2 threads. The gains at 6 and 8 threads exceeded 5×.
  • % improvement. The same pattern as a percentage. At 6 and 8 threads, the improvement was above 80%.

Raw trial data#

Every one of the 60 timed runs, in milliseconds.

Threads Run 1 Run 2 Run 3 Run 4 Run 5 Run 6 Run 7 Run 8 Run 9 Run 10 Run 11 Run 12 Avg
1 3.921 3.671 3.813 3.690 3.759 3.702 3.704 3.740 3.724 3.924 3.725 3.680 3.754
2 4.560 4.207 4.273 4.252 4.244 4.217 4.362 4.771 4.240 4.205 4.347 4.348 4.335
4 3.022 3.077 3.171 3.116 3.139 3.113 3.071 2.823 3.446 3.139 3.119 3.094 3.111
6 0.747 0.634 0.685 0.678 0.592 0.708 0.848 0.616 0.631 0.758 0.772 0.707 0.698
8 0.537 0.788 0.588 0.773 0.611 1.013 0.567 0.571 0.650 0.639 0.515 0.533 0.649

Reading the raw runs#

  • The 1-thread baseline is stable at about 3.7 ms.
  • The 2-thread runs are slower in every trial, so the slowdown is consistent and not a one-off.
  • The 4-thread runs cluster tightly, which points to a small but consistent gain.
  • The 6-thread runs are very fast, with moderate variation.
  • The 8-thread runs are usually the fastest, but one run passed 1.0 ms, which shows some scheduling noise.

Why averages matter

One fast or slow run does not describe a configuration. The average over 12 runs gives a fairer comparison.

Run evidence#

The Excel summary and the console output of all twelve benchmark runs.

Excel benchmark summary

Run 1

Run 2

Run 3

Run 4

Run 5

Run 6

Run 7

Run 8

Run 9

Run 10

Run 11

Run 12

The raw spreadsheet is available as benchmark-results.xlsx.

Machine specifications#

Item Value
Processor model Apple M2
Physical cores 8 (4 performance + 4 efficiency)
Logical cores (threads) 8
RAM 8 GB
Operating system macOS Tahoe 26.3.1
Java version OpenJDK 25 LTS (Temurin)

Result statement#

Conclusion

Multithreading helped this workload, but only once there were enough threads to outweigh the overhead. The data supports 8 threads as the best measured configuration, and 6 threads also performed very well.