6.1.12 · D3Parallelism & Multicore

Worked examples — Heterogeneous computing concepts

1,854 words8 min readBack to topic

Back to the parent topic.


The scenario matrix

Every problem in this topic is one of a small number of shapes. The table below is the full menu. Each of the worked examples underneath is tagged with the cell it covers, and together they touch every row.

Cell Scenario class The question it tests Degenerate / limiting edge
A High arithmetic intensity Is big enough to beat transfer? : GPU always wins
B Low arithmetic intensity Same, but the task is data-heavy : never offload
C Exact break-even Where does hetero = CPU-only?
D Amdahl with serial floor How much serial fraction kills speedup? : pure parallel
E Amdahl, infinite GPU The ceiling nobody can pass
F Transfer-tax dominance When the PCIe tax, not compute, rules large
G Pipeline, balanced stages Speedup as all equal
H Pipeline, one bottleneck Slowest stage caps throughput one rest
I Real-world word problem Translate English → symbols
J Exam twist (unified memory) Removing entirely

We keep re-using these master formulas from the parent, restated once so every symbol is earned:


Example 1 — Cell A: high arithmetic intensity (GPU wins big)

Forecast: matrix multiply is the poster child for GPUs ( work, data). Guess: yes, easily.

  1. Compute the break-even work threshold. Why this step? The formula tells us the minimum that makes offloading pay; we then check our real against it.
  2. Compare. Why? Offload is worth it exactly when actual work exceeds the threshold. Actual FLOP GFLOP.

Verify: actual hetero time . CPU-only ms. Hetero is faster — consistent with "offload." ✓


Example 2 — Cell B: low arithmetic intensity (GPU loses)

Forecast: one add per three memory touches — this is the "terrible for GPUs" case the parent warned about. Guess: don't offload.

  1. Break-even threshold. Why? Same test as before, now with a data-heavy task.
  2. Compare. Why? Actual GFLOP.

Verify: hetero time ms; CPU-only ms. Hetero is 750× slower — the transfer tax buried a trivial compute. ✓ (Arithmetic intensity FLOP/byte, far below the 70 FLOP/byte crossover.)


Example 3 — Cell C: the exact break-even point

Forecast: the parent worked this and got GFLOP. Let's confirm and see it.

Figure — Heterogeneous computing concepts
  1. Set the two times equal. Why? Break-even is by definition .
  2. Solve for . Why? We want the crossover work.

Verify: at TFLOP, hetero s and CPU s — equal. ✓ Look at the figure: to the right of the amber line GPU wins (Cell A), to the left CPU wins (Cell B). One line splits the whole world.


Example 4 — Cell D & F: Amdahl with serial floor and transfer tax

Forecast: GPU is 50× but serial + tax will crush it — guess low double digits.

  1. Plug into heterogeneous Amdahl. Why? It's the master speedup formula.
  2. Attribute the loss. Why? To see which term hurts. Serial contributes , tax , parallel only to the denominator. The two fixed costs () dwarf the compute term.

Verify: — matches parent's . ✓


Example 5 — Cell E: infinite GPU (the ceiling)

Forecast: the term vanishes, leaving only fixed costs. Guess: around 14×.

  1. Take the limit. Why? To find the hard ceiling no hardware can beat.
Figure — Heterogeneous computing concepts

Verify: ✓ The curve in the figure rises then flattens at 14.29 — proof that after some point, buying a faster GPU buys you nothing. This is exactly Amdahl's Law and Scalability in heterogeneous clothing.


Example 6 — Cell D edge: zero serial fraction

Forecast: no serial floor — should be much closer to 50×.

  1. Substitute. Why? To see the degenerate best case.

Verify: . ✓ Notice: even with zero serial code the answer is 25, not 50 — the transfer tax alone halves it. The tax is a serial cost in disguise.


Example 7 — Cell J: unified memory removes the tax

Forecast: removing 0.02 from the denominator should push us above 14×.

  1. Recompute. Why? Isolate the value of eliminating data movement.
  2. Compare to Ex. 4. Why? To quantify the win. vs — a 29% improvement just from unified memory.

Verify: ; ratio . ✓ Ties directly to Memory Hierarchy and Caching and DMA and I/O Controllers — the whole point of DMA/unified memory is shrinking that term.


Example 8 — Cell G: balanced pipeline

Forecast: three equal stages → speedup approaches 3.

Figure — Heterogeneous computing concepts
  1. Sequential time. Why? Baseline with no overlap.
  2. Pipelined time. Why? First item pays full latency, then we sustain at the slowest stage's rate.
  3. Speedup. , and as .

Verify: . ✓ The figure's staircase shows stages fully overlapping — a new image starts every 4 ms once the pipe is full.


Example 9 — Cell H: one bottleneck stage

Forecast: compute is 5× the others — throughput is limited by 10 ms, so speedup ≈ , not 3.

  1. Sequential. ms. Why? Baseline.
  2. Pipelined. . Why? The pipe drips out one result every 10 ms after fill.
  3. Speedup. , limit .

Verify: ✓ Lesson: a pipeline is only as fast as its slowest station — balance the stages (relates to load balancing in Parallel Programming Models).


Example 10 — Cell I: real-world word problem

Forecast: 8 TFLOP of work over 4 GB → intensity FLOP/byte, sky-high. Guess: strongly offload.

  1. Break-even threshold. Why? Decision test.
  2. Compare. Actual GFLOP GFLOP offload. Why? Work is 30× the threshold.
  3. Quantify the win. Why? Managers want a number.

Verify: ; threshold TFLOP. ✓ Units check: . ✓


Recall Self-test — cover the answers

Which cell has speedup capped even with an infinite GPU? ::: Cell E — capped at . Vector add vs matrix multiply: which is Cell B (don't offload)? ::: Vector add (low arithmetic intensity, work / data). In a balanced 3-stage pipeline the speedup approaches ___ ? ::: 3, i.e. . Unified memory improves speedup by setting which term to zero? ::: (Cell J). The break-even threshold grows with which quantity, hurting offload? ::: Data size (bigger transfers need more work to justify).