Exercises — Heterogeneous computing concepts
Throughout, we reuse the parent note's symbols. To keep the contract, here they are in one place, in plain words:
Level 1 — Recognition
L1.1
Classify each chip as CPU-like (latency-optimised) or GPU-like (throughput-optimised): (a) 8 powerful cores with megabytes of cache and branch prediction; (b) 2048 tiny ALUs sharing a small cache, running one instruction across many threads; (c) a fixed-function block that only does AES encryption.
Recall Solution
- (a) CPU-like — few strong cores + big caches + branch prediction all serve latency of one task.
- (b) GPU-like — thousands of simple lanes running SIMT (Single Instruction, Multiple Threads) serve throughput of many tasks. See SIMD and Vector Processing.
- (c) Neither general type — it is a specialized accelerator (fixed-function). Narrow domain, so hardwired logic wins on energy.
L1.2
A system has 4 identical ARM cores. Is it heterogeneous? Now it adds 1 GPU and 1 NPU. Now?
Recall Solution
- 4 identical cores = homogeneous (same instruction set, same strengths).
- Adding a GPU + NPU = heterogeneous — two or more different processor types with distinct computational models.
Level 2 — Application
L2.1
PCIe link with GB/s. You must move GB to the GPU and the result back. How long does the round-trip transfer take?
Recall Solution
Round-trip means data crosses twice, so the moved amount is .
L2.2
Same link. Your GPU runs at TFLOP/s; your CPU at TFLOP/s. Using the parent's break-even formula, what is the minimum work that makes the GPU worthwhile for that 1 GB?
Recall Solution
Plug in , , , (all in matching TFLOP/s and GB/s units, giving TFLOP): What it means: unless the task needs at least ~69 billion operations, the 62.5 ms trip costs more than it saves. The arithmetic intensity floor is FLOP/byte.
L2.3
Matrix–matrix multiply of two matrices needs FLOPs and moves bytes (three float32 matrices). Compute arithmetic intensity for . Is it above the 69 FLOP/byte floor?
Recall Solution
FLOP. bytes MB. Intensity FLOP/byte. ✓ — matrix multiply clears the floor comfortably. This is why GEMM loves GPUs. Contrast — vector add. Adding two length- float32 arrays does FLOPs (one add per element) but moves bytes (read two operands, write one result, 4 bytes each). So intensity FLOP/byte — one measly add per 12 bytes moved, hopeless for a GPU. See Roofline Performance Model.
Level 3 — Analysis
L3.1
Heterogeneous Amdahl's Law. A program is parallel, serial, GPU speedup , transfer tax (5% of original time). Find overall speedup.
Recall Solution
Even with a 20× engine, we get ~5×. The serial floor plus tax cap us. See Amdahl's Law and Scalability.
L3.2
Take L3.1 and set (infinitely fast GPU). What is the hard ceiling on speedup? What single change would raise that ceiling the most?
Recall Solution
As , the term : The ceiling is set entirely by serial fraction + transfer tax, not by GPU speed. The biggest lever: cut (parallelise more code) or (unified memory removes copies — see Memory Hierarchy and Caching). Buying a faster GPU past this point is wasted money.
L3.3
Pipeline. Four stages take ms per image. Process images. Compare sequential vs pipelined time and give the speedup.
Figure below (alt: a Gantt-style timeline). The top strip shows the sequential schedule — every stage of every image laid end-to-end, so time just adds up. The bottom strip shows the pipelined schedule — each new image starts one bottleneck-length ( ms) after the previous, so all four stages run concurrently and the tallest bar () sets the rhythm. The horizontal axis is time in ms; each colour is one stage.

Recall Solution
Sum of stages ms. Slowest stage ms. Sequential: ms. Pipelined: ms. Speedup: . As the limit is . The slow 5 ms stage is the bottleneck — speeding any other stage does nothing. See Parallel Programming Models.
Level 4 — Synthesis
L4.1
You must decide CPU-only vs heterogeneous for a task with GFLOP and GB, on the L2 machine (, , TFLOP/s). Compute both times and decide.
Recall Solution
CPU alone: s. Heterogeneous: s. , so CPU wins. Makes sense: GFLOP is below the L2.2 floor of 69.4 GFLOP. Not enough work to pay the transfer toll.
L4.2
Redesign: keep GB but raise the work to GFLOP (denser algorithm). Recompute both. Now who wins, and by how much?
Recall Solution
CPU: s. Hetero: s. Speedup: . GPU now wins clearly — same data, more work per byte crossed the break-even line. Lesson: raising arithmetic intensity, not just chip speed, unlocks the GPU.
L4.3
Given a 3-stage pipeline (read on CPU, compute on GPU, write on CPU) with per-image times ms, and images — pick which stage to optimise if you can halve exactly one stage. Compute pipelined time for each choice and justify.
Recall Solution
Baseline pipelined: ms.
- Halve read (4→2): , still 10 → ms. Barely moves.
- Halve compute (10→5): , new → ms. Huge.
- Halve write (3→1.5): , still 10 → ms. Negligible. Pick compute — it is the bottleneck (). Only shrinking the tallest stage lowers sustained throughput.
Level 5 — Mastery
L5.1
Full system design. A neural-net training step: (matrix ops), , , current . (a) Find current speedup. (b) You buy unified memory that drops to . New speedup? (c) What is the absolute ceiling () with the new tax, and what should you attack next?
Recall Solution
(a) (b) Replace : (c) Ceiling: Since GPU speed is nearly maxed (the term is small), the next target is the serial fraction — parallelise data loading / loss / parameter updates. Also relevant: Power and Energy Optimization and DMA and I/O Controllers to overlap those transfers.
L5.2
Cost-effectiveness ranking. For the L5.1 baseline (), rank three upgrades by resulting speedup: (i) double GPU speed ; (ii) halve serial fraction (moving that 2.5% into , so ); (iii) halve transfer tax .
Recall Solution
- (i)
- (ii)
- (iii) Ranking: (ii) 15.50× > (iii) 12.66× > (i) 12.58×. Attacking the serial fraction wins by a mile — because at the parallel term is already tiny, so doubling the GPU barely helps. Amdahl's ceiling is the boss.