Exercise 2: Re-Running the Small-Workload Benchmark With 2 Processes — Possible Solution ==================================================================== WHAT CHANGED ------------------------------ Only the worker count changed, from 4 (this chapter's own test) to 2 - the same 8-calculation workload and the same cpu_heavy_pricing_calc() function are used unchanged. RESULTS WITH 2 PROCESSES ------------------------------ SMALL workload (8 calcs): sequential=0.074s, parallel(2)=0.200s, speedup=0.37x COMPARING TO THIS CHAPTER'S OWN 4-PROCESS RESULT ------------------------------ 4 processes: sequential=0.069s, parallel(4)=0.207s, speedup=0.33x (~3x slower) 2 processes: sequential=0.074s, parallel(2)=0.200s, speedup=0.37x (~2.7x slower) VERIFYING THE FINDING STILL HOLDS ------------------------------ Yes - with only 2 processes instead of 4, parallelizing this small workload is STILL slower than running it sequentially (0.37x speedup, meaning it took roughly 2.7x longer). The exact ratio shifted slightly (2.7x slower instead of ~3x slower), but the core finding - overhead dominates for a workload this small - held regardless of how many processes were used. WHY REDUCING THE WORKER COUNT DIDN'T FIX IT ------------------------------ The overhead this chapter's own finding identified isn't primarily about HOW MANY processes get spawned - it's that spawning ANY additional process at all costs real, measurable time (process creation, inter-process communication to send work and collect results), and this workload's own total useful work (8 calculations, each fast) is too small to amortize even that baseline cost. Using 2 processes instead of 4 reduces the number of separate spawn/ communication round-trips slightly, which is why the ratio improved marginally (0.33x -> 0.37x) - but it doesn't eliminate the underlying problem, since even ONE extra process still has to be spawned and communicated with. WHY THIS WORKS AS AN ANSWER ------------------------------ The benchmark is re-run with only the worker count changed, keeping this chapter's own workload and methodology identical, and the resulting ratio is directly compared against this chapter's own 4-process number rather than reported as a standalone figure - showing the finding is robust to this specific parameter rather than an artifact of choosing 4 processes specifically.