GPU vs CPU design philosophy: Question bank — Hinglish deep dive

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

Yeh page GPU vs CPU design philosophy ka self-test bank hai. Neeche har line ek trap hai: ek aisi baat jo sahi lagti hai jab tak tum dhyan se sochte nahi. Left side padho, ek ya do sentences mein uthkar jawab do, phir reveal karo.

True or false — justify

A GPU core is faster than a CPU core

False. Har individual GPU core per instruction slow hota hai (koi branch prediction nahi, koi out-of-order nahi, lower clock); GPU sirf isliye jeetता hai kyunki yeh hazaaron slow cores ek saath chalata hai.

A GPU always beats a CPU

False. Sirf throughput wale kaam mein jahan bahut saare independent tasks hon. Ek akele sequential task par (ek thread of dependent steps) CPU ki low latency jeetती hai — neeche binary-search trap dekho.

CPUs cannot do parallel work

False. CPUs ke paas multiple cores (8–16) hote hain aur yeh threads parallel mein chalate hain; yeh bas zyaadatar transistors har thread ko fast banane mein lagate hain, na ki bahut saare threads rakhne mein.

More cores always means more throughput

False. Throughput sirf tabhi cores ke saath badhta hai jab tumhare paas unhe feed karne ke liye kaafi independent tasks hon aur kaafi memory bandwidth ho; idle cores kuch nahi dete (yeh GPU model mein

O cc u p an cy

term hai).

A larger cache would make a GPU faster

False in general. Cache per core mehanga hota hai; hazaaron cores par, har ek ko bada cache dene se arithmetic ke liye koi transistor budget nahi bachega. GPU latency ko thread switching se hide karta hai, caching se nahi.

Branch prediction would help a GPU a lot

False mostly. GPU latency ko is tarah hide karta hai ki doosre warps ready rehte hain, isliye use serial CPU ki tarah speculation ki zaroorat nahi; predictors lagana un transistors ko barbad karna hoga jo cores par better spend ho sakte hain.

Higher clock frequency is the main reason CPUs feel "fast"

Partly false. Clock help karta hai, lekin dominant reason ki single tasks jaldi khatam hoti hain woh hai caches, branch prediction, aur out-of-order execution se high IPC — clocks toh saalon se barely badhe hain.

The GPU's advantage comes from a higher clock speed

False. GPU clocks usually CPU clocks se lower hote hain. Advantage parallel cores ki sankhya se hai, clock speed se nahi.

If a workload has data dependencies between steps, a GPU still helps

False. Dependent steps order mein hi chalane padte hain; exploit karne ke liye koi parallelism nahi hai, toh GPU ke slower cores cheez ko aur bura bana dete hain.

Occupancy of 100% is always achievable and always ideal

False. Register aur shared-memory limits resident warps ko cap karti hain, isliye occupancy typically 0.5–0.9 hoti hai; aur jab latency poori tarah se hide ho jaati hai, extra occupancy se koi aur speedup nahi milta.

Spot the error

"GPUs are faster because they have more transistors."

Galat reason. A100 ke paas zyaada transistors hain, lekin baat yeh hai ki woh kaise kharch hote hain — arithmetic units par kaafi bada fraction jaata hai, na ki caches aur control logic par. Kharchne ka tarika kahaani hai, raw count nahi.

"The CPU wastes most of its die on caches, which is bad design."

Galat judgement. Woh caches isliye hain taaki sequential code ke liye memory latency kam ho sake (100 ns DRAM → 1–4 ns cache hit) — yeh CPU ke liye excellent design hai latency question ke liye jiska CPU jawab deta hai.

"A warp is 32 separate programs running independently."

Galat. Ek warp 32 threads hain jo sab lockstep mein same instruction execute karte hain (SIMT). Woh instruction stream share karte hain; sirf unka data alag hota hai.

"When a warp stalls on memory, the whole GPU stalls."

Galat. Scheduler turant doosre ready warp par switch kar leta hai, isliye arithmetic units kaam karte rehte hain. Yahi switching exactly hai jisse GPU DRAM latency ko bina caches ke hide karta hai.

"Speedup for the blur example is unlimited if we add more cores."

Galat. Speedup memory bandwidth, independent pixels ki sankhya, aur eventually kisi bhi serial portion se cap hota hai — Amdahl's law dekho.

t_{in s t r u c t i o n}

being higher on a GPU means the GPU is a bad design."

Galat. Jab

N_{t a s k s} ≫ N_{cor es}

ho, per-instruction latency parallelism se hide ho jaati hai, isliye zyaada

t_{in s t r u c t i o n}

total time par barely asar dalta hai — yeh trade-off intentional hai.

"Both CPU and GPU follow the von Neumann model, so their performance is basically the same."

Galat. Dono von Neumann fetch-execute idea share karte hain, lekin unka microarchitecture (kitne cores, latency kaise hide hoti hai) unhe behaviour mein bilkul opposite banata hai.

Why questions

Why do CPUs use out-of-order execution but GPUs use in-order?

CPU ke paas few threads hain, isliye use parallelism ek instruction stream ke andar (ILP) reordering ke through extract karna padta hai. GPU ke paas hazaaron threads hain, isliye woh parallelism threads ke across dhundta hai aur ek ke andar reorder karne ki zaroorat kabhi nahi padti.

Why does a GPU need many resident warps per SM?

DRAM latency ke hundreds of cycles hide karne ke liye: jab dozens of warps memory par wait kar rahe hote hain, doosre arithmetic units ko busy rakhte hain. Bahut kam warps honge toh cores idle reh jaayenge.

Why do branches hurt GPUs more than CPUs?

Ek warp sab 32 threads ke liye ek instruction run karta hai; agar threads alag branches lein, toh hardware ko paths serialize karna padta hai (branch divergence), doosrein ko mask karte hue har side karna padta hai — yeh wasted work hai jo SIMT model avoid nahi kar sakta.

Why can't a GPU just add a big branch predictor and beat the CPU at everything?

Woh transistor budget fixed hai (

C_{co m pl e x} \approx 10 \times C_{s im pl e}

). Usse prediction par kharcha karne ka matlab hai fewer cores, jisse throughput advantage khatam hota hai jo GPU ke exist karne ka pura reason hai.

Why is the restaurant analogy (chef vs cafeteria) actually accurate?

Chef (CPU) time per order minimize karta hai — latency; cafeteria (GPU) orders per hour maximize karta hai — throughput. Har ek doosre ke kaam mein by design worse hai, jo exactly CPU/GPU split hai.

Why does maximizing

P

(processor count) help even if

t_{t a s k}

goes up?

Kyunki

T_{t o t a l} = \frac{N}{P} \times t_{t a s k}

: bade

N

ke liye, bade

P

se divide karna time ko us se tezi se shrink karta hai jitna

t_{t a s k}

mein modest rise badhata hai — isliye zyaada cores paane ke liye slower cores accept karna ek net win hai.

Edge cases

What happens on a GPU when

N_{t a s k s} = 1

GPU CPU se worse hota hai: sirf ek slow core useful kaam karta hai, baaki hazaaron idle rehte hain, aur koi latency hide karne ke liye nahi hoti. Yeh degenerate serial case hai.

What happens when

N_{t a s k s} \approx N_{cor es}

(not

≫

GPU ka throughput advantage lagbhag gayab ho jaata hai; memory stalls hide karne ke liye koi surplus threads nahi hain, cores idle rehte hain aur slower per-instruction time dominate karne lagta hai.

What happens if every thread in a warp takes a different branch?

Worst case: sab 32 paths serialize ho jaate hain, toh warp us region ke liye 32× tak slow ho jaata hai — SIMT model ek 32-wide unit ko effectively 1-wide mein badal deta hai.

What if the workload fits entirely in the CPU's L3 cache but is huge on the GPU?

CPU jeet sakta hai: cache hits use ~1–4 ns memory access dete hain jabki GPU DRAM ko hundreds of ns pay karta hai. Chota, cache-friendly, latency-bound kaam CPU ko favour karta hai.

Occupancy = 0 — what does the GPU model predict?

T_{GP U} \to \infty

: koi core actively compute nahi kar raha, toh kuch khatam nahi hota. Yeh flag karta hai ki zero active warps wala GPU zero useful work karta hai chahe core count kitna bhi ho.

What if a "parallel" task secretly has one serial bottleneck (a global sum step)?

Woh serial fraction total speedup ko cap kar deta hai chahe kitne bhi cores add karo — iska formal statement Amdahl's law hai; parallel model

T = N / P \cdot t

sirf fully independent part ke liye hold karta hai.

Zero-latency memory (hypothetical) — would the GPU still need many warps?

Nahi. Warps mainly memory latency hide karne ke liye exist karte hain; agar memory instant hoti toh hide karne ke liye kuch nahi hota, aur GPU far fewer resident warps ke saath chal sakta tha.

Recall Quick self-scoring

Which single word decides whether GPU or CPU wins a workload? ::: Kya tasks independent hain (parallel → GPU) ya dependent (serial → CPU). The GPU's core advantage in one phrase? ::: Zyaada transistors arithmetic par kharch aur latency thread-switching se hide hoti hai, caches ki jagah. The CPU's core advantage in one phrase? ::: Ek single dependent thread ke liye low latency via caches, branch prediction, aur out-of-order execution.

See also: 6.3.01-SIMD-vs-SIMT · 6.2.02-CUDA-programming-model · 6.2.03-memory-hierarchy-GPU · 9.2.01-parallel-programming-models · 6.2.01 GPU vs CPU design philosophy (Hinglish)