Worked examples — Multicore vs manycore designs

This page is the "boss fight" for the parent topic. We will take the two formulas the parent introduced — the speedup formula from Amdahl's Law and the throughput formula — and push them into every corner: the easy cases, the broken cases, the "it's exactly zero" cases, and the ones that look like they should favour one design but secretly favour the other.

Before any numbers, let's re-anchor the two symbols we will use over and over, because a good chunk of "wrong answers" come from mixing them up.

Here are the exact formulas we'll be feeding, copied from the parent so no symbol is used unearned:

Two chips will recur through the examples, so let's fix their parameters once here and name them, rather than sneaking numbers in mid-problem:

---

The scenario matrix

Every question this topic can throw at you lands in one of these cells. The worked examples below are labelled with the cell they cover, and together they hit all of them.

Cell	The "input extreme" being tested	What it probes
A	$P=0$ (nothing parallel)	Serial floor — degenerate low end
B	$P=1$ (perfectly parallel)	The manycore dream — degenerate high end
C	$0<P<1$, small $N$	Realistic multicore
D	$N\to \infty$ (limiting behaviour)	Amdahl's ceiling
E	Throughput vs latency clash	Same chips, opposite winners
F	Area/transistor tradeoff	Why the two philosophies exist
G	Utilization collapse ($U\to$ small)	When manycore's flood dries up
H	Real-world word problem	Picking a design from a description
I	Exam twist (the trap)	Where "obvious" answer is wrong

---

Worked examples

Example 1 — Cell A: nothing is parallel ($P=0$)

1. Write down $P$. "100% serial" means the parallel fraction $P=0$. Why this step? Translating English ("serial") into the symbol the formula eats is where most errors happen — $P$ is the parallel fraction, so serial-only means $P=0$, not $P=1$.
2. Substitute into Amdahl: $S=\frac{1}{(1-0)+\frac{0}{512}}=\frac{1}{1+0}=1$ Why this step? The $\frac{P}{N}$ term is the only place $N$ appears. If $P=0$, that whole term vanishes and $N$ becomes invisible — the cores literally cannot touch this problem.
3. Interpret: $S=1$ means "exactly as fast as one core." The other 511 cores sit idle. Why this step? A degenerate case must be named so you recognise it live: dependency chains defeat parallelism entirely.

Verify: Plug $N=1$ (one core, the baseline) into the same formula: $S=\frac{1}{1+0}=1$. Same answer as $N=512$ — confirming extra cores added nothing. Units: speedup is dimensionless (a ratio of times), and $1$ is the "no change" value. ✓

---

Example 2 — Cell B & D: perfect parallelism, then the limit

1. Confirm $P=1$. Independent entries ⇒ zero serial fraction. Why this step? $P=1$ is the only value that lets speedup grow without a ceiling — so verifying it is worth the second.
2. Part (a): $S=\frac{1}{(1-1)+\frac{1}{6912}}=\frac{1}{0+\frac{1}{6912}}=6912$. Why this step? With the serial term $(1-P)=0$ gone, speedup becomes exactly $N$ — linear scaling, the manycore dream.
3. Part (b), the limit: as $N\to \infty$, $\frac{1}{N}\to 0$, so $S\to \frac{1}{(1-P)+0}=\frac{1}{1-P}=\frac{1}{0}\to \infty .$ Why this step? This is the ONLY $P$ for which the limit is infinite. It shows the boundary between Cells B and D: perfect parallelism has no ceiling; anything less does (next example).

Verify: Reality check — the parent notes actual A100 speedup is ~4000×, less than 6912×. That's consistent: our $S=6912$ is the theoretical max (utilization $U=1$); memory bandwidth drags real $U$ below 1, so real speedup < 6912. The model over-estimates, never under-estimates — correct direction. ✓

---

Example 3 — Cell D: Amdahl's ceiling for imperfect $P$

1. Take the limit $N\to \infty$: $S_{\max }=\frac{1}{1-P}=\frac{1}{1-0.95}=\frac{1}{0.05}=20.$ Why this step? This is the single most important consequence of Amdahl: a mere 5% serial slice caps you at 20×, forever.

   Now look at the figure below. Each curve is $S(P,N)$ for a fixed $P$ as we crank $N$ rightward. The blue $P=0.95$ curve climbs steeply at first, then bends over and presses flat against the red dashed line at $20$ — that red line is exactly the $S_{\max }=1/(1-P)$ we just computed. The picture is the visual proof of this step: no matter how far right you go (more cores), the curve can never cross its ceiling.

2. Find $N$ for half the ceiling ($S=10$): solve $\frac{1}{0.05+\frac{0.95}{N}}=10$. Then $0.05+\frac{0.95}{N}=0.1\Rightarrow \frac{0.95}{N}=0.05\Rightarrow N=\frac{0.95}{0.05}=19$. Why this step? It exposes the cruelty of the curve: 19 cores get you to $10\times$, but reaching $20\times$ needs infinitely many. In the figure this is the white dot at $(19,10)$ — notice it sits only halfway up to the red ceiling even though we already spent 19 cores. Everything to the right of that dot is the region of diminishing returns.

Verify: Plug $N=19$ back: $S=\frac{1}{0.05+0.95/19}=\frac{1}{0.05+0.05}=\frac{1}{0.1}=10$. ✓ And $10=20/2$, exactly half the ceiling. ✓

---

Example 4 — Cell C: realistic multicore, small $N$

1. Substitute $P=0.30$, $N=8$: $S=\frac{1}{(1-0.30)+\frac{0.30}{8}}=\frac{1}{0.70+0.0375}=\frac{1}{0.7375}.$ Why this step? The serial term $0.70$ dominates the denominator — that's the "killer" the parent warned about. It's fixed no matter how many cores you add.
2. Compute: $S=\frac{1}{0.7375}\approx 1.36$. Why this step? A tiny speedup — yet multicore is still the right choice here (see step 3), which is the whole point.
3. Compare the base core speeds. A single REF-CPU core does $f\times \text{IPC}=4\text{GHz}\times 4=16$ GIPS; a single REF-GPU core does $1.5\text{GHz}\times 1=1.5$ GIPS — the REF-CPU core is $16/1.5\approx 10.7\times$ faster on one thread. Since 70% of this workload runs on one thread, that base speed dominates; the modest $1.36\times$ parallel bonus rides on top of an already-fast core. Why this step? Speedup is relative to a single core; the base core matters. Using the named REF-CPU / REF-GPU numbers (instead of vague "high IPC") makes the comparison concrete: multicore wins branchy code because its base thread is ~10× quicker, not because of core count.

Verify: $1/0.7375=1.3559\dots \approx 1.36$. ✓ Base-speed ratio $16/1.5=10.67$. ✓ Sanity: with $P<1$, $S$ must be strictly less than $N=8$ and greater than $1$ — and $1<1.36<8$ holds. ✓

---

Example 5 — Cell E: same two chips, throughput flips the winner

One small unit note before we compute. $f_{\text{clock}}$ (in GHz) is clock ticks per second; $\text{IPC}$ is instructions per tick. Multiplying them, the "ticks" cancel: $f_{\text{clock}}\times \text{IPC}$ has units of instructions per second — that's the honest per-core work rate, and it's what "single-thread performance" means here. (Below, the shorthand $4\times 4=16$ means "16 giga-instructions per second on one core," since $4\text{ GHz}\times 4\text{ IPC}$.)

1. REF-CPU throughput: $\Theta =8\times 4\times 4\times 0.9=115.2$ GIPS. Why this step? Multiply the four factors of the throughput formula; GHz × IPC gives billions of instructions/sec per core, ×cores×U gives the chip total.
2. REF-GPU throughput: $\Theta =512\times 1.5\times 1\times 0.7=537.6$ GIPS. Why this step? Same formula, opposite balance: tiny per-core numbers, huge core count. The count wins the product.
3. Ratio: $537.6/115.2=4.667\approx 4.7\times$ → REF-GPU wins throughput. Why this step? Confirms the firehose beats the eyedropper on volume.
4. Single-thread: one core does $f\times \text{IPC}$ instructions per second. REF-CPU: $4\times 4=16$ GIPS; REF-GPU: $1.5\times 1=1.5$ GIPS. Ratio $16/1.5=10.67\times$ → REF-CPU wins latency. Why this step? Shows the flip: the throughput loser is the latency winner. Same silicon, opposite verdicts, depending on the question you asked.

Verify: $8\cdot 4\cdot 4\cdot 0.9=115.2$ ✓; $512\cdot 1.5\cdot 1\cdot 0.7=537.6$ ✓; $537.6/115.2\approx 4.667$ ✓; $16/1.5\approx 10.667$ ✓. Units: GIPS = giga-instructions per second (a rate) for throughput; the single-thread numbers ($16$, $1.5$) are also GIPS but per core, so you must not compare them against the whole-chip totals — hence two separate ratios. ✓

---

Example 6 — Cell F: the transistor tradeoff, from area

1. Complex cores: $N_{\text{complex}}=200/10=20$. Why this step? Area budget ÷ area-per-core = count. The die is the fixed pie; each fat core takes a big slice.
2. Simple cores: $N_{\text{simple}}=200/0.2=1000$. Why this step? Same pie, thinner slices ⇒ vastly more of them.
3. Ratio: $\frac{N_{\text{simple}}}{N_{\text{complex}}}=\frac{A_{\text{complex}}}{A_{\text{simple}}}=\frac{10}{0.2}=50$. Why this step? The ratio doesn't even need the die size — it's just the area ratio. One fat core = fifty skinny ones. This is the physical reason the two philosophies can't coexist: Power Consumption and area are one fixed budget you spend once.

Now compare that arithmetic to the figure below. The left panel is a single die tile filled almost entirely by one blue $10{\text{mm}}^2$ core — the multicore way, spending everything on being big and clever. The right panel is the same-size tile (see the yellow "same area" arrow bridging them) tiled by a $10\times 5$ grid of $50$ tiny green $0.2{\text{mm}}^2$ cores — the manycore way. The eye sees instantly what step 3 proved: one fat core and fifty skinny cores occupy identical silicon. That equal area is the whole reason "you can't have both."

Verify: $200/10=20$ ✓; $200/0.2=1000$ ✓; $1000/20=50=10/0.2$ ✓. Units: mm² / mm² = dimensionless count. ✓

---

Example 7 — Cell G: utilization collapse (the manycore flood dries up)

1. Recompute REF-GPU throughput with $U=0.1$: $\Theta =512\times 1.5\times 1\times 0.1=76.8$ GIPS. Why this step? $U$ multiplies everything linearly — divergence (see SIMD vs MIMD) is the manycore's kryptonite because its cores share instruction streams and stall together.
2. Compare: $76.8<115.2$ → REF-CPU now wins even on throughput. Why this step? This is the degenerate case for the manycore side: when the workload is irregular, its numerical advantage evaporates. It answers "when does a firehose lose to an eyedropper?" — when the firehose is 90% air.
3. Solve for the break-even $U$ (part b): set REF-GPU throughput equal to REF-CPU's 115.2 GIPS and solve for $U$: $512\times 1.5\times 1\times U=115.2\Rightarrow 768U=115.2\Rightarrow U=\frac{115.2}{768}=\mathrm{0.15.}$ Why this step? It converts the vague worry "manycore sometimes loses" into an exact, predictable threshold. Below $U=0.15$ the REF-GPU falls behind the REF-CPU; above it, the REF-GPU wins. Now you can forecast the winner from workload regularity alone, without re-running the whole calculation — the single most useful number in this cell.

Verify: $512\cdot 1.5\cdot 0.1=76.8$ ✓; $76.8<115.2$ ✓; $115.2/768=0.15$ ✓ — and indeed the normal $U=0.7$ (Example 5) is well above $0.15$, consistent with REF-GPU winning there, while $U=0.1$ sits below $0.15$, consistent with it losing here. ✓

---

Example 8 — Cell H: real-world word problem

1. Classify the database. Query planning is sequential with unpredictable branches; index traversal is pointer chasing; locks are serial critical sections ⇒ low $P$, irregular. → multicore. Why this step? Low parallel fraction + branchy control flow is exactly Cell A/C territory where core count can't help and fast single-thread (Thread-Level Parallelism with few strong threads) matters.
2. Classify the training loop. Dense matmul ⇒ $P\approx 1$, regular, Cache Coherence-light, bandwidth-bound. → manycore. Why this step? $P\approx 1$ is Cell B — the only regime where thousands of cores pay off linearly.
3. Decision: database → multicore CPU; training → manycore GPU. If forced to buy exactly one, pick by which service is the bottleneck on revenue: if latency-per-transaction is what customers pay for, buy the multicore CPU and rent GPU time for occasional training; if the product is the trained model, buy the manycore GPU and run the database on the existing host CPU. The genuinely correct architecture, though, is to keep both and route each workload to the chip it suits — this is exactly the Heterogeneous Computing design pattern. Why this step? It forces the reader to notice that "which is better" is always workload-relative; there is no universal winner, and real systems resolve the dilemma by using both.

Verify: Cross-check with Example 4 (branchy 30%-parallel → multicore $S\approx 1.36$, base-speed matters) and Example 2 ($P=1$ matmul → manycore $S\approx N$). Both worked examples agree with this classification. ✓

---

Example 9 — Cell I: the exam trap

1. Spot the trap: $P=0.90$, not $1.0$. The naive reader multiplies by core count. Why this step? The word "90% parallel" is deliberately close to 100% to tempt you into linear scaling. Only $P=1$ scales linearly (Example 2).
2. Compute properly: $S=\frac{1}{(1-0.9)+\frac{0.9}{1000}}=\frac{1}{0.1+0.0009}=\frac{1}{0.1009}$. Why this step? Include the serial $0.1$ term — the one the trap wants you to forget.
3. Result: $S\approx 9.91$. The ceiling ($N\to \infty$) is only $\frac{1}{0.1}=10\times$. Why this step? $\approx 9.91\times$, nowhere near $1000\times$. Answer: FALSE. 1000 cores buy you 99% of a measly $10\times$ ceiling.

Verify: $1/(0.1+0.9/1000)=1/0.1009=9.9108\dots \approx 9.91$ ✓; ceiling $1/0.1=10$ ✓; and $9.91<10$ (must be below the limit) ✓. ✓

---

Recall Quick self-test

A 100% serial task on 512 cores gives speedup? ::: Exactly $1$ — cores are useless (Cell A). The speedup ceiling for $P=0.95$? ::: $1/(1-0.95)=20\times$ (Cell D). One 10 mm² core equals how many 0.2 mm² cores? ::: $10/0.2=50$ (Cell F). Below what utilization does the 512-core REF-GPU lose to the 115.2 GIPS REF-CPU? ::: $U=0.15$ (Cell G). "90% parallel on 1000 cores ≈ 1000×" — true or false? ::: False, it's $\approx 9.91\times$, ceiling $10\times$ (Cell I).