Parallel speedup
Throwing more workers at a job only helps if the work can actually be split. Speedup measures it: sequential time / parallel time. Independent tasks divide cleanly and you get real speedup; a chain where each step waits for the last cannot be parallelized at all, no matter how many workers you add. Switch on the Gantt chart and watch the difference — and try Predict mode to call the parallel time before it's revealed.
Run four tasks on two workers and measure the speedup over running them one at a time.
Click a line, drag the slider, or use the ← → keys.
What you are looking at
Four tasks, 8 ticks of work in total, two workers. The Gantt chart has one lane per worker; each block is a task, drawn across the time it runs. The speedup is computed live.
- Procedural — independent tasks, scheduled onto whichever worker is free. Both lanes stay busy, the run finishes in 4 ticks, and
speedup = 8/4 = 2. Clean parallelism. - Buggy — the same tasks, but each depends on the one before it. The blocks march across the timeline one after another even though there are two lanes, so the run still takes 8 ticks and
speedup = 8/8 = 1. Two workers bought nothing. Sequential dependencies are the ceiling on parallel speedup — the single most-missed idea in this corner of the course.
The schedule and timings are real execution output; that this models real parallel hardware is a modelling claim (marked model: author-asserted) — see how GlassBox stays honest.