GPU vs CPU design philosophy: Worked examples — Hinglish deep dive

6.2.1 · D3 · Hardware › GPU Architecture › GPU vs CPU design philosophy

Yeh page GPU vs CPU design philosophy ki drill ground hai. Parent note ne tumhe bataya tha kyun CPUs latency ke peeche bhagte hain (ek kaam jaldi khatam karo) aur GPUs throughput ke peeche (ek second mein zyada se zyada kaam khatam karo). Yahan hum us idea ko har tarah ke workload ke saath takrate hain — jinmein GPU mileage laita hai, jinmein woh haarta hai, aur beech ke tricky edge cases.

Koi bhi number dekhne se pehle, poora battlefield samajh lete hain.

The scenario matrix

Har workload ko neeche diye gaye cell mein se ek mein daalo. Agar tum kisi nayi problem ko kisi cell mein classify kar sako, toh arithmetic karne se pehle hi jaante ho kaun jeega.

Cell	Case class	Kya cheez ise is class mein daalta hai	Winner (expected)
A	Massively parallel, independent	Millions of tasks, koi task doosre par depend nahin karta	GPU (big)
B	Strictly sequential	Har step ko pichle step ka result chahiye	CPU
C	Zero / degenerate size	Bahut kam kaam ( $N \approx 1$ )	CPU (launch cost matters)
D	Limiting case $N \to \infty$	Task count badhta jaata hai bina ruke	GPU (ratio → core ratio)
E	Branch divergence	Parallel hai lekin threads alag paths lete hain	GPU, but degraded
F	Memory-latency bound	Bahut saari slow DRAM reads, thoda sa compute	GPU (hides latency)
G	Partly parallel (Amdahl)	Ek serial fraction parallelize hone se mana karta hai	Capped — dekho 9.1.02-Amdahls-law
H	Real-world word problem	Ek described situation, tumhe classify karna hai	Story se decide karo
I	Exam twist	Ek cell jaisa lagta hai, actually doosra hai	Dhyan se padho!

Neeche, har symbol wahi hai jo parent ke do performance models mein tha. Unhe dobara anchor karte hain taaki yeh page apne aap mein poori ho.

Recall The two formulas we will keep using

CPU (latency model): $T_{C P U} = \frac{N _{in s t}}{I P C \times f}$ — ek thread ke liye time, $N_{in s t}$ = instructions ki sankhya, $I P C$ = ek clock tick mein kitne instructions finish hote hain, $f$ = ticks per second. GPU (throughput model): $T_{GP U} = \frac{N _{t a s k s}}{N _{cor es} \times O cc \times f} \times C P I$ — saare tasks ke liye total time jo $N_{cor es}$ cores par spread hain, $O cc$ = fraction of cores jo busy hain, $C P I$ = cycles per instruction (ek GPU core ko ek CPU core se zyada clock ticks chahiye ek instruction ke liye — isliye hum isko $f$ se divide karne ke baad multiply karte hain).

Definition "ns-per-task-per-core" shorthand jo hum neeche use karenge

$f$ (cycles/s) aur $C P I$ (cycles/instruction) ko alag alag handle karna jhanjhat wala hai. Notice karo ki ek fixed core ke liye ek fixed kaam karte waqt, yeh product $t_{cor e} = \frac{C P I \times ( instructions per task )}{f}$ sirf ek measured time in seconds hai — "ek core ko ek task khatam karne mein kitna waqt lagta hai." Hum ise ns-per-task-per-core kehte hain aur $t_{cor e}$ likhte hain. Yeh parent ke $f$ aur $C P I$ (aur per-task instruction count) ko ek hi number mein fold kar leta hai jo tum stopwatch se measure kar sakte ho. Tab parent ka GPU model is friendly form mein collapse ho jaata hai $T_{GP U} = \frac{N _{t a s k s}}{N _{cor es} \times O cc} \times t_{cor e},$ aur CPU model $T_{C P U} = \frac{N _{t a s k s}}{N _{cor es}^{C P U}} \times t_{cor e}^{C P U}$ mein. Neeche har worked number ek $t_{cor e}$ hai (jaise " $1 ns$ ", " $2 ns$ "), isliye hum $f$ aur $C P I$ ko haath se juggle nahin karte — lekin tum unhe hamesha boxed formula se unfold kar sakte ho.

Ab examples. Steps padhne se pehle winner guess karo.

Worked example Example 1 — Cell A: Independent, massively parallel (vector add)

Problem: Do arrays ke $N = 1 0^{7}$ numbers ko element by element add karo: $c_{i} = a_{i} + b_{i}$ . CPU ke paas $16$ cores hain; GPU ke paas $4096$ cores hain. Abhi memory ignore karo — pure compute.

Forecast: Kaun jeega, aur roughly kitne factor se? Apna guess likho.

Classify. Har $c_{i}$ sirf $a_{i}, b_{i}$ par depend karta hai, kisi aur cheez par nahin → tasks independent hain. → Cell A. Yeh step kyun? Independence hi woh permission slip hai jo sare cores ko ek saath use karne ki ijazat deta hai.
Equal- $t_{cor e}$ assumption state karo. Is ek, chhoti instruction ke liye (ek single add), maano ki CPU core aur GPU core dono ise same $t_{cor e}$ mein khatam karte hain. Matlab hum $t_{cor e}^{C P U} = t_{cor e}^{GP U}$ set karte hain, jo dono ke liye equal $C P I / f$ fold karta hai. Yeh step kyun? Parent ke models sirf $N_{cor es}$ , $O cc$ aur $t_{cor e}$ mein differ karte hain. Agar hum $t_{cor e}$ ko pin nahin karte, toh " $256 \times$ " secretly ek per-core speed difference absorb kar leta — ek hidden assumption. Yeh state karna clean ratio ko honest banata hai. (Examples 2 aur 4 is equality ko tod te hain on purpose taaki dikhe kya badalta hai.)
CPU time. $O cc = 1$ ke saath: $T_{C P U} = \frac{1 0 ^{7}}{16} \times t_{cor e} = 625, 000 t_{cor e}$ ( $16$ cores, $625, 000$ tasks each). Yeh step kyun? Ek latency machine apna slice ek ek karke khatam karta hai; $\frac{N}{N _{cor es}}$ wahi slice hai.
GPU time. $O cc = 1$ ke saath: $T_{GP U} = \frac{1 0 ^{7}}{4096} \times t_{cor e} \approx 2442 t_{cor e}$ . Yeh step kyun? Ek throughput machine same kaam ko bahut zyada workers mein spread karta hai.
Speedup ratio. Kyunki $t_{cor e}$ aur $N_{t a s k s}$ upar neeche dono mein equal hain, woh cancel ho jaate hain: $\frac{T _{C P U}}{T _{GP U}} = \frac{N _{cor es}^{GP U}}{N _{cor es}^{C P U}} = \frac{4096}{16} = 256 \times .$ Yeh step kyun? Sirf haathon ki sankhya bachti hai — Cell A ka poora point yahi hai.

Verify: $625000/2442 \approx 256$ . Wahi number do tarike se → consistent. Units: (tasks/core)÷(tasks/core) dimensionless hai, pure speedup. ✓

Figure padho: left panel mein CPU ke $16$ magenta tiles hain, har ek par "625k" stamp hai — kuch cores bade bade slices khaa rahe hain. Right panel mein $4096$ chote cores ka ek dense violet grid hai, har ek ke paas kaam ka ek chhota sa tukda. Orange caption " $256 \times = 4096/16$ " bilkul step 5 hai: dono taraf ke tiles gino, ratio lo.

Worked example Example 2 — Cell B: Strictly sequential (binary search)

Problem: $1 0^{9}$ elements ki sorted array mein binary search karo. CPU: $2 ns$ per iteration (branch predictor + cache warm). GPU: $5 ns$ per iteration (simple core, no prediction). Yahan $t_{cor e}^{C P U} \neq = t_{cor e}^{GP U}$ — hum deliberately Example 1 ki equality tod rahe hain.

Forecast: Ek task, tees dependent steps. Kaun jeega?

Iterations gino. Binary search har step mein range half karta hai, isliye ise $lo g_{2} (1 0^{9})$ steps chahiye. Yeh step kyun? Har comparison pichle comparison ka result use karta hai — yeh sequential, cell B ki definition hai.
Log evaluate karo. $lo g_{2} (1 0^{9}) = 9 lo g_{2} 10 \approx 9 \times 3.3219 \approx 29.9 \to 30$ iterations. Yeh step kyun? Hume per-step time se multiply karne ke liye ek concrete step count chahiye.
CPU total. $30 \times 2 ns = 60 ns$ . Yeh step kyun? Sirf ek thread of work ke saath, $N_{cor es}$ irrelevant hai ( $N_{t a s k s} = 1$ chain); total time sirf steps × per-step $t_{cor e}^{C P U}$ hai.
GPU total. $30 \times 5 ns = 150 ns$ . Yeh step kyun? GPU ke 4096 cores bekaar hain — sirf ek thread of work hai, isliye iska slower $t_{cor e}^{GP U}$ ab ek pure penalty hai aur iske peeche kuch chhupane ko nahin.
Ratio. $\frac{T _{GP U}}{T _{C P U}} = \frac{150}{60} = 2.5 \times$ — CPU 2.5× jeeta hai.

Verify: $2^{30} = 1, 073, 741, 824 > 1 0^{9}$ , isliye $30$ halvings kaafi hain. ✓ GPU/CPU ratio per-step ratio $5/2 = 2.5$ ke barabar hai kyunki dono same number of steps karte hain. ✓

Worked example Example 3 — Cell C: Zero / degenerate input (4 numbers add karo)

Problem: Sirf $N = 4$ elements ke do arrays add karo. GPU kernel launch overhead $\approx 5 μ s$ hai; har core add $\approx 2 ns$ mein karta hai. CPU 4 adds $1 ns$ each mein ~ $0$ overhead ke saath karta hai.

Forecast: Chhota sa problem. Kya mighty GPU phir bhi jeega?

Classify. $N = 4$ cores ki sankhya se bahut kam hai → machine fill nahin ho sakti. → Cell C (degenerate). Yeh step kyun? Throughput tabhi faydemand hoti hai jab bahut zyada tasks hon; yahan hain hi nahin.
CPU time. $4 \times 1 ns = 4 ns$ , koi launch cost nahin. Yeh step kyun? Char independent adds, koi per-launch tax nahin — CPU bas karta hai unhe.
GPU time. Launch $5000 ns$ + compute $2 ns \approx 5002 ns$ . Yeh step kyun? Fixed startup cost chahe $N$ kuch bhi ho pay karna padta hai; tiny $N$ ke saath yeh poora dominate karta hai.
Ratio. $\frac{T _{GP U}}{T _{C P U}} = \frac{5002}{4} \approx 1250 \times$ GPU par slower.

Verify: Jaise jaise $N \to 0$ , $T_{GP U} \to$ launch overhead (ek constant), jabki $T_{C P U} \to 0$ . Isliye GPU ratio blow up karta hai — hamare $1250 \times$ se match karta hai. ✓ Units: ns/ns, dimensionless. ✓

Worked example Example 4 — Cell D: Limiting behaviour

$N \to \infty$ Problem: Example 1 ka vector add lo lekin GPU ka $5 μ s$ launch overhead include karo. CPU: $t_{cor e}^{C P U} = 1 ns$ , $16$ cores. GPU: $t_{cor e}^{GP U} = 2 ns$ (slower core — equality phir se todi), $4096$ cores. $N = 1 0^{3}$ , $N = 1 0^{6}$ , aur limit $N \to \infty$ par speedup kya hai?

Forecast: Kya speedup hamesha badhti rehti hai, ya koi ceiling hai?

Dono times ko $N$ ke function ke roop mein likho. $T_{C P U} (N) = \frac{N}{16} \times 1 ns, T_{GP U} (N) = 5000 ns + \frac{N}{4096} \times 2 ns .$ Yeh step kyun? Ek limit dekhne ke liye hume $N$ ko variable rakhna hoga, fixed number nahin.
Chhota $N = 1 0^{3}$ . $T_{C P U} = \frac{1000}{16} = 62.5 ns$ ; $T_{GP U} = 5000 + \frac{1000}{4096} \cdot 2 \approx 5000.5 ns$ → CPU jeeta hai ( $\sim 80 \times$ ). Yeh step kyun? Chhote $N$ par constant $5000 ns$ launch cost tiny compute term ko swamp kar deta hai — yeh Cell-C regime curve mein ghus aata hai.
Medium $N = 1 0^{6}$ . $T_{C P U} = \frac{1 0 ^{6}}{16} = 62, 500 ns$ ; $T_{GP U} = 5000 + \frac{1 0 ^{6}}{4096} \cdot 2 \approx 5000 + 488 = 5488 ns$ → GPU jeeta hai $\approx 11.4 \times$ . Yeh step kyun? Ab compute itna badh gaya hai ki fixed launch cost dwarf ho jaata hai, toh GPU ki parallelism pay karne lagti hai — lekin overhead abhi bhi ratio ko uske ceiling se neeche kheench raha hai.
Limit $N \to \infty$ . Overhead $N$ -term ke saath negligible ho jaata hai: $lim_{N \to \infty} \frac{T _{C P U}}{T _{GP U}} = \frac{N /16}{N /4096 \cdot 2} = \frac{4096}{16 \times 2} = 128 \times .$ Yeh step kyun? Upar neeche $N$ se divide karne par constant $5000$ mar jaata hai — classic limit trick. Note karo ceiling $128$ hai, $256$ nahin, kyunki GPU core yahan $2 \times$ slower hai.

Verify: $\frac{4096}{32} = 128$ . ✓ $N = 1 0^{6}$ par humne $11.4 \times$ paya, ceiling $128 \times$ se bahut neeche — consistent, kyunki overhead ek million par abhi bhi matter karta hai. Crossover (GPU pakad leta hai) wahan hai jahan $T_{C P U} = T_{GP U}$ : solve karne par $N \approx 8.1 \times 1 0^{4}$ milta hai, hamare small aur medium points ke beech. ✓

Figure padho: magenta curve actual speedup hai jaise $N$ log axis par badhta hai — yeh dotted "break-even" line se neeche shuru hota hai (CPU jeetta hai, step 2 ka small- $N$ region), $N \approx 8 \times 1 0^{4}$ ke paas orange dot par cross karta hai, phir chadhta hai aur step 4 ki violet dashed " $128 \times$ " ceiling ki taraf flatten ho jaata hai. Yeh flattening hi limit ka visible roop hai.

Worked example Example 5 — Cell E: Branch divergence (if/else in a warp)

Problem: Ek GPU warp = $32$ threads jo har cycle mein same instruction execute karte hain. Ek kernel mein hai if (x>0) doA(); else doB(); jahan $d o A$ aur $d o B$ dono $10 ns$ lete hain. Ek warp mein $20$ threads if lete hain, $12$ else lete hain. Warp kitna time leta hai vs. ek ideal no-divergence warp?

Forecast: Saare 32 threads ek saath chalte hain — toh kya yeh abhi bhi $10 ns$ hai?

Classify. Tasks parallel hain lekin alag paths lete hain → Cell E. Yeh step kyun? SIMT (dekho 6.3.01-SIMD-vs-SIMT) ek shared instruction force karta hai, isliye divergence free nahin hai.
SIMT divergence handle kaise karta hai. Hardware dono branches run karta hai, us path par nahin wale threads ko mask off karta hai — yeh dono branches ko serialize karta hai. Yeh step kyun? Per-thread instruction pointer ke bina, woh doA aur doB ko same cycle mein nahin run kar sakta.
Divergent time. $d o A$ (10 ns, else-threads idle) phir $d o B$ (10 ns, if-threads idle) $= 20 ns$ . Yeh step kyun? Kyunki step 2 kehta hai paths serialize hote hain, hum unke times ko add karte hain overlap karne ki jagah — yeh masking ki concrete cost hai.
Ideal (no divergence) time. Agar saare $32$ ek branch lete: $10 ns$ . Yeh step kyun? Hume penalty measure karne ke liye ek baseline chahiye — "no divergence" case woh best hai jo warp kabhi bhi kar sakta hai.
Slowdown. $\frac{20}{10} = 2 \times$ — divergence ne cost double kar di. Yeh step kyun? Divergent ko ideal se divide karne par sirf divergence ke kaaran aayi penalty isolate hoti hai, base work time strip ho jaati hai.

Verify: $k$ distinct branch paths ke saath equal length $t$ ki, time $= k \cdot t$ . Yahan $k = 2$ , $t = 10 ns$ → $20 ns$ . ✓ Worst case $k = 32$ (har thread alag) dega $32 \times$ — ek useful sanity bound. ✓

Worked example Example 6 — Cell F: Memory-latency bound (image blur, latency hiding)

Problem: $8.3 \times 1 0^{6}$ pixels blur karo; har ek ko $9$ DRAM reads $200 ns$ each par plus $5 ns$ compute chahiye. GPU par, jab ek warp memory ka wait karta hai, scheduler doosre warps run karta hai. CPU (16 cores, L3 hits $10 ns$ /read + $5 ns$ compute + $10 ns$ write) $105 ns$ /pixel leta hai.

Forecast: GPU par memory reads $20 \times$ slower hain — kya woh phir bhi jeet sakta hai?

Classify. Pixels independent, bahut zyada, memory waits se dominated → Cell F.
CPU total. Har core: $\frac{8.3 \times 1 0 ^{6}}{16} \approx 518, 750$ pixels $\times 105 ns \approx 54.5 ms$ . Yeh step kyun? CPU apni badi L3 cache par rely karta hai reads cheap banane ke liye ( $10 ns$ ), phir sequentially grind karta hai.
GPU par per-pixel raw work. Ek pixel ko $9 \times 200 ns + 5 ns = 1805 ns$ stall + compute chahiye agar ek akela core kare. Yeh catastrophic hoga — isliye hum core ko idle wait karne nahin dete. Yeh step kyun? Latency hide karne ki baat karne se pehle hume usse size karna hoga — tum ek number hide nahin kar sakte jo tumne measure hi nahin kiya.
Latency hiding + core count se effective per-pixel cost nikalo. Chip ke paas $8704$ cores hain; jab koi ek $1805 ns$ wait karta hai, baaki cores pixels retire karte hain. Agar latency fully hidden ho, chip roughly ek pixel har $\frac{1805 ns}{8704 cores} \approx 0.207 ns$ mein complete karta hai; ek modest occupancy/scheduling overhead ise $\approx 0.24 ns$ per pixel wall-clock throughput tak round up karta hai. Yeh step kyun? Yahi core baat hai: latency ÷ overlapping workers ki sankhya = effective throughput cost. $200 ns$ kabhi nahin ghata — woh hazaron cores ke beech divided hua jo wait ke dauran kaam kar rahe the.
GPU total. $8.3 \times 1 0^{6} \times 0.24 ns \approx 2.0 ms$ . Yeh step kyun? Hidden per-pixel throughput cost ko pixel count se multiply karo wall-clock time pane ke liye — same "tasks × cost-per-task" shape jaise har doosra example, bas ek hidden cost ke saath.
Speedup. $\frac{54.5 ms}{2 ms} \approx 27 \times$ . Yeh step kyun? Dono totals ko divide karne par forecast ka jawab milta hai: $20 \times$ slower reads ke bawajood, hiding $27 \times$ se jeetti hai.

Verify: $518750 \times 105 ns = 54.47 ms$ ✓. $\frac{1805}{8704} = 0.207 ns$ , aur $0.24 ns$ (with overhead) $\times 8.3 \times 1 0^{6} \approx 1.99 ms$ ✓. $54.47/2 \approx 27$ ✓. Key lesson: GPU ne $200 ns$ latency kabhi reduce nahin ki — usne ise doosre kaam ke peeche hide kar diya (6.2.03-memory-hierarchy-GPU).

Worked example Example 7 — Cell G: Partly parallel (Amdahl's ceiling) — aur

$O cc$ kahan rehta hai Problem: Ek program $95%$ parallelizable hai, $5%$ strictly serial. Tum ise effectively "infinite" cores wale GPU par move karte ho. Maximum speedup kya hai? Phir: agar sirf $60%$ cores busy rehte hain ( $O cc = 0.6$ ) instead of $100%$ , toh yeh parent ke GPU model mein kaise enter karta hai, aur ek realistic combined speedup kaisa dikhta hai?

Forecast: Infinite cores → infinite speedup? Ek number guess karo.

Classify. Ek fixed serial fraction parallelize hone se mana karti hai → Cell G, governed by 9.1.02-Amdahls-law. Yeh step kyun? Koi bhi non-parallel work ki presence ceiling ko poori tarah badal deti hai, isliye hume pehle woh fraction name karna hoga.
Amdahl's law state karo. Serial fraction $s$ aur $P$ processors ke saath: $Speedup (P) = \frac{1}{s + \frac{1 - s}{P}} .$ Yeh step kyun? Total time = serial part (kabhi nahin ghatta) + parallel part ( $P$ se ghatta hai); us time ka reciprocal, $P = 1$ ke relative, speedup hai.
$P \to \infty$ lo. Parallel term $\frac{1 - s}{P} \to 0$ ho jaata hai, bachta hai $Speedup_{m a x} = \frac{1}{s} = \frac{1}{0.05} = 20 \times .$ Yeh step kyun? Chahe kitne bhi cores hon, un-parallelizable $5%$ time par ek hard floor hai — zero parallel work cores se divide karne par bhi serial slice erase nahin hoti.
$O cc$ kahan rehta hai — plug it in. $T_{GP U} = \frac{N _{t a s k s}}{N _{cor es} \times O cc} \times t_{cor e}$ mein, occupancy $N_{cor es}$ se multiply karta hai: sirf $O cc \times N_{cor es}$ cores actually kaam retire karte hain. Toh Amdahl's law mein effective processor count $P_{e f f} = O cc \times N_{cor es}$ hai. Yeh step kyun? $O cc$ koi alag mystery nahin hai — yeh sirf parallel machine ko shrink karta hai. $P \to P_{e f f}$ substitute karne se ek formula dono effects carry kar sakta hai.
Realistic combined number. $N_{cor es} = 4096$ aur $O cc = 0.6$ ke saath: $P_{e f f} = 0.6 \times 4096 \approx 2458$ . Tab $Speedup = \frac{1}{0.05 + \frac{0.95}{2458}} \approx 19.85 \times .$ Yeh step kyun? Yeh honest outcome dikhata hai: 4096 cores par 60% occupancy ke saath bhi, Amdahl ki $20 \times$ ceiling — occupancy nahin — result pin karta hai. Occupancy tab zyada matter karta hai jab serial fraction dominate karna shuru nahin ki ho.
Pure occupancy penalty isolate karo. Agar ek workload fully parallel ho ( $s = 0$ ) aur $t_{cor e}$ term se dominated ho, toh $O cc$ ko $1.0$ se $0.6$ karna akela $T_{GP U}$ ko $\frac{1}{0.6} \approx 1.67 \times$ inflate karta hai. Yeh step kyun? Dono effects ko alag karne se dikhta hai kab occupancy bite karta hai: yeh throughput-bound code ko directly hurt karta hai ( $1.67 \times$ yahan), lekin mask ho jaata hai jab ek serial fraction lower ceiling set kar deta hai.

Verify: $s = 0.05, P = 4096$ par (ideal $O cc = 1$ ): $\frac{1}{0.05 + 0.95/4096} \approx 19.9 \times$ ✓. $P_{e f f} = 2458$ par: $\approx 19.85 \times$ ✓ — barely different, proving ceiling dominates. Pure occupancy check: $1/0.6 \approx 1.667$ ✓. Isliye cell G capped hai, aur real GPUs rarely apni paper peak hit karti hain. ✓

Figure padho: teen curves (magenta $s = 5%$ , violet $s = 10%$ , orange $s = 25%$ ) sab processors $P$ badhne ke saath chadhti hain lekin har ek apni dashed ceiling $1/ s$ = $20 \times$ , $10 \times$ , $4 \times$ par flatten ho jaati hai. Serial slice jitni chhoti, ceiling utni unchi — lekin har curve badhna band ho jaati hai. Woh plateau step 3 ka visible roop hai.

Worked example Example 8 — Cell H: Real-world word problem (payroll vs particles)

Problem: Tumhe (a) CEO ke liye ek PDF pay-slip generate karni hai, aur (b) ek movie frame ke liye $2 \times 1 0^{6}$ independent smoke particles ki positions simulate karni hain. Tumhare paas ek CPU aur ek GPU hai (16 vs 4096 cores). Har kaam sahi device ko assign karo aur justify karo — phir particle speedup estimate karo.

Forecast: Kaun sa kaam kahan jaata hai, aur (b) kitne se jeeta hai?

Classify (a). Ek document, sequential formatting logic, bahut saari branches (fonts, tables). $N \approx 1$ → Cell C/B → CPU. Yeh step kyun? Parallelize karne ke liye kuch hai hi nahin; CPU ka branch predictor aur cache branchy, single-thread kaam par shine karta hai.
Classify (b). $2 \times 1 0^{6}$ particles, har ek same physics se update hota hai, baaki se independent → Cell A/F → GPU. Yeh step kyun? Identical independent tasks ki badi sankhya GPU ki home turf hai — exactly woh "independent AND many" dono-haan wala case.
Particle speedup estimate karo. Near-equal $t_{cor e}$ assume karte hue (jaise Cell A mein) aur $O cc \approx 0.7$ : $P_{e f f} = 0.7 \times 4096 \approx 2867$ , toh $\frac{T _{C P U}}{T _{GP U}} \approx \frac{P _{e f f}}{N _{cor es}^{C P U}} = \frac{2867}{16} \approx 179 \times .$ Yeh step kyun? Hum Cell-A core-ratio result reuse karte hain lekin occupancy se discount karte hain (Example 7 se) ek realistic — paper-peak nahin — figure paane ke liye.

Verify: Rule check — "independent AND many?" (a) Nahin → CPU. (b) Haan → GPU ✓. Number: $\frac{0.7 \times 4096}{16} = 179.2$ ✓, sensibly ideal $256 \times$ ceiling se neeche kyunki $O cc < 1$ . ✓

Worked example Example 9 — Cell I: The exam twist (parallel lagta hai, serial hai)

Problem: "Array ka running total (prefix sum) compute karo: $o u t_{i} = a_{0} + a_{1} + \dots + a_{i}$ . $1 0^{6}$ elements hain aur yeh sirf addition hai — toh kya yeh embarrassingly parallel hai? Naive speedup compute karo, phir catch dhundho."

Forecast: Kya prefix sum cell A hai... ya ek trap?

Dependency pakdo. $o u t_{i} = o u t_{i - 1} + a_{i}$ . Har output ko pichle output ki zaroorat hai. Yeh step kyun? Naive definition ek chain hai → Cell B lagta hai, A nahin. Yahi twist hai.
Naive serial cost. $1 0^{6}$ dependent additions, ek ke baad ek → core-count speedup bilkul nahin ( $1 \times$ ) is tarike se karne par. Yeh step kyun? Ek dependency chain poore kaam ko ek core par pin kar deta hai, chahe kitne bhi idle hon — isliye $N_{cor es}$ model se poori tarah bahar ho jaata hai.
Real resolution. Ek parallel scan algorithm (Blelloch) kaam ko independent partial sums ke ek tree mein restructure karta hai, $1 0^{6}$ ki jagah sirf $lo g_{2} (1 0^{6}) \approx 20$ dependent stages mein. Yeh step kyun? Algorithm badalne se cell badal jaata hai — yeh B ko ek shallow-A mein convert karta hai. Dekho 9.2.01-parallel-programming-models aur 6.2.02-CUDA-programming-model.
Parallel-scan depth. $lo g_{2} (1 0^{6}) = 6 lo g_{2} 10 \approx 6 \times 3.3219 \approx 19.9 \to 20$ stages. Yeh step kyun? Hume depth (dependent stages ki sankhya) chahiye — woh, element count nahin, set karta hai ki kaam abhi bhi kitna sequential hai, aur isliye achievable speedup kya hai.

Verify: $2^{20} = 1, 048, 576 \geq 1 0^{6}$ ✓, toh $20$ tree stages ek million elements cover karte hain. Lesson: cell algorithm par depend karta hai, sirf problem statement par nahin — exam ka "surely parallel?" bait hai. ✓

Recall Rapid self-test (answers chhupa lo)

Independence bahut saare cores use karne ki permission hai ::: Iske bina tum ek core par stuck ho (cell B). GPU bade $N$ par bahut jeetta hai lekin uski speedup ceiling hai ::: core ratio (Ex. 1: $256 \times$ ; Ex. 4 slower cores ke saath: $128 \times$ ). Tiny $N = 4$ wala kaam ::: CPU par fast chalta hai, kyunki GPU launch overhead ( $\sim 5 μ s$ ) kaam ko dwarf karta hai (cell C). Warp divergence with 2 equal paths ka cost hai ::: $2 \times$ (paths serialize hote hain; general: paths × path-length). $5%$ serial code ke saath max speedup kabhi bhi ho sakta hai ::: $20 \times$ by Amdahl ( $1/ s$ ), chahe kitne bhi cores hon. GPU memory-bound blur par CPU ko harata hai ::: $200 ns$ latency doosre warps ke peeche hide karke (latency ÷ overlapping cores = effective cost). Occupancy model mein enter karta hai cores ko shrink karke ::: $P_{e f f} = O cc \times N_{cor es}$ (Ex. 7); pure penalty $= 1/ O cc$ , jaise $1/0.6 \approx 1.67 \times$ . Ek word problem solve karne ke liye poochho ::: "independent AND many?" — payroll → CPU, 2M particles → GPU (Ex. 8). Prefix sum parallel lagta hai lekin secretly hai ::: ek dependency chain (cell I); ek parallel scan ise $lo g_{2} N \approx 20$ stages tak cut karta hai.

Next: parent GPU vs CPU design philosophy aur 6.2.01 GPU vs CPU design philosophy (Hinglish) version dobara dekho, phir Example 5 ke peeche divergence machinery ke liye 6.3.01-SIMD-vs-SIMT mein jaao.