Objective#
Evaluate how execution time changes when the Java program computes the sum of cubes with 1, 2, 4, 6 and 8 threads.
Controlled conditions#
Same machine#
Every official run used the same laptop. Nothing else about the hardware or OS changed between configurations.
Same input#
The same array size for every thread count, with integer values strictly below 100.
Computation only#
Only the computation is timed. Array creation, setup and printing are excluded.
Verified output#
Each parallel result is checked against the single-thread result before its time counts.
Execution environment#
| Item | Value |
|---|---|
| Machine | MacBook Air |
| Processor | Apple M2 |
| Cores | 8 total (4 performance + 4 efficiency) |
| RAM | 8 GB |
| Operating system | macOS Tahoe 26.3.1 |
| Java runtime | OpenJDK 25 LTS (Temurin) |
Measurement method#
Bracket the computation#
Call System.nanoTime() immediately before and after the computation.
Convert to milliseconds#
(end - start) / 1_000_000.0. currentTimeMillis() is too coarse for runs this short and can report 0 ms.
Repeat#
Run each thread configuration 12 times under the same setup.
Average#
Compute the mean for each configuration, then derive the metrics below.
Metrics#
Execution time#
The average across 12 runs, in milliseconds.
Speedup#
Speedup = T(1) / T(n)
% improvement#
((T(1) - T(n)) / T(1)) × 100
Questions the analysis answers#
- Where does performance improve the most?
- At which thread count do gains flatten?
- Does performance decrease at higher thread counts?
- Which overheads explain the trend: thread creation, scheduling, context switching or core limits?
Observed outcome#
What the plan produced
- 2 threads added overhead and ran slower than the baseline.
- 4 threads gave only a modest improvement.
- 6 and 8 threads gave the strongest gains.
- 8 threads had the best average runtime overall. 6 threads was very close and slightly more stable in some runs.