Multicore vs manycore designs: Visual walkthrough — Hinglish deep dive

6.1.4 · D2 · Hardware › Parallelism & Multicore › Multicore vs manycore designs

Yeh page multicore vs manycore ka central result bilkul zero se build karta hai: woh equation jo decide karti hai ki aapko kuch fast cores chahiye ya bahut saare slow cores. Woh equation hai Amdahl's Law. Hum yeh assume nahi karenge ki aapne isse pehle kabhi dekha hai. Hum isse draw karke samjhenge, ek ek bar karke.

Definition Is game ke idealized rules

Amdahl's Law ek best-case model hai. Kuch bhi draw karne se pehle, is page ke har picture mein baki teen assumptions ke baare mein honest raho:

Perfect load-balancing — parallel kaam bilkul equal pieces mein split hota hai, isliye har core ek hi pal mein khatam hota hai. Koi core idle nahi baithta wait karte hue.
Zero overhead — kaam ko split karna, cores ko start karna, aur results ko merge karna kuch bhi kharch nahi karta. Real systems cache coherence traffic aur thread startup ka cost pay karte hain; hum yahan isse ignore kar rahe hain.
No communication cost — cores kabhi ek doosre ka ya shared memory ka wait nahi karte. Reality mein yeh aapke gains kha jaata hai.

Toh hum jo bhi speedup compute karein woh ek ceiling hai — jo aap kabhi bhi pa sakte ho woh maximum. Real hardware hamesha kam karta hai. Yeh caveat apni jeb mein rakhna baaki poore page ke liye.

Step 1 — Kaam ko ek time ki bar ke roop mein draw karo

KYA. Cores ko ek pal ke liye bhool jao. Ek program lo aur use ek core par chalao. Dekho kitna time lagta hai. Us total time ko $T_{orig}$ kaho — poori bar ki length.

KYUN. Speedup hamesha ek comparison hota hai: naya time versus purana time. Isliye pehle ek baseline chahiye. Baad ki har cheez is ek bar ke saath measure hoti hai.

PICTURE. Neeche ki poori bar $T_{orig}$ hai. Humne abhi kuch split nahi kiya hai — yeh "pehle" ki picture hai.

Step 2 — Bar ko do honest pieces mein split karo

KYA. Bar ko do parts mein colour karo. Ek part woh code hai jo parallel chal sakta hai (ek saath kai workers). Doosra part woh code hai jo ek step at a time chalna chahiye — splitting allowed nahi.

KYUN. Sab code equal nahi hota. Ek million numbers ki list add karna? Split karo — yeh parallel hai. Lekin "config file padho, PHIR engine start karo, PHIR level load karo" — har step ko pichla step pehle complete hona chahiye. Yeh serial hai. Poori story is ek split par tiki hai.

PICTURE. Laal slice serial part hai — woh part jo sirakna refuse karega chahe aap kitne bhi cores khareed lo. Kaala slice parallel hai.

T_{orig} = cannot split T_{serial} + can split T_{parallel}

Step 3 — Pieces ko fractions mein badlo (size-free banao)

KYA. Seconds mein measure karne ki bajaye, har piece ko poori bar ka fraction measure karo. $P$ ko parallel fraction hone do. Toh serial fraction jo bacha woh hai: $1 - P$ .

KYUN. Seconds machine, input, aur weather par depend karte hain. Ek fraction nahi karta. Yeh kehna ki "is program ka 90% parallel hai" ( $P = 0.9$ ) ek program ke baare mein fact hai, kisi bhi hardware par sach. Isliye hum units divide out karte hain — yeh law code ke baare mein hona chahiye, clock ke nahi.

PICTURE. Wahi bar, ab baayein $0$ aur daayein $1$ label ki gayi. Laal serial slice ki width $1 - P$ hai; kaali parallel slice ki width $P$ hai.

Step 4 — Parallel slice ko $N$ cores ko do

KYA. Ab machinery. Hum finally cores ki sankhya ka naam lete hain. == $N$ == ko cores ki sankhya hone do jo hum program ko dete hain. Use $N$ cores do (dekho thread-level parallelism ki kaise woh cores ko feed milta hai). Parallel slice saare $N$ mein share ho jaata hai — toh yeh apni purani length ka $\frac{1}{N}$ ho jaata hai. Serial slice bilkul nahi sirkta: ek worker, ek step at a time.

KYUN. Parallel hardware ka poora point yahi hai: splittable kaam ko split karo. Agar $N = 4$ cores mein se har ek parallel kaam ka quarter leta hai, toh woh piece quarter time mein khatam hoti hai — aur yahan "perfect load-balancing" ka idealized assumption apna kaam karta hai: hum assume karte hain ki har core ko exactly equal quarter milta hai. Lekin serial piece ke paas kaam dene ke liye koi nahi hai — woh full length par atki hai.

PICTURE. Dekho kaali parallel slice $\frac{P}{N}$ par collapse hoti hai jabki laal serial slice bilkul same width par rehti hai. Laal bar poori story ka villain hai — isko ghoorte raho.

Step 5 — Speedup ko ek naam milta hai: $S$ = purani bar ÷ nayi bar

KYA. Ab hum woh quantity define karte hain jo hum dhundh rahe the aur ise ek symbol dete hain. == $S$ == ko speedup kehne do — nayi bar kitni baar chhoti hai. Purani length ko nayi length se divide karo.

KYUN. "Do baar fast" literally matlab "aadha time", yaani old÷new $= 2$ . Yahi ratio hum compute karte hain. Ise $S$ kehne se hum ise ek baar likh sakte hain aur clearly reason kar sakte hain. Yeh ek definition hai, koi trick nahi.

PICTURE. Purani bar (length $1$ ) shrunken nayi bar (length $(1 - P) + \frac{P}{N}$ ) ke upar baithi hai. Speedup $S$ hai ki purani mein kitni nayi bars fit hoti hain.

Step 6 — $N$ ko infinity tak push karo: wall appear hoti hai

KYA. Extreme sawaal pucho: kya hoga agar hamare paas infinitely many cores hote? $N \to \infty$ hone do. Tab $\frac{P}{N} \to 0$ .

KYUN. Poore topic mein yeh single most important sentence hai. Yeh hume best case ever batata hai, woh ceiling jo hardware ki koi bhi matra beat nahi kar sakti. Agar ceiling low hai, toh aur cores kharidna bekar hai — aur tabhi manycore haarta hai.

PICTURE. Jaise $N$ badhta hai, parallel slice ek baal tak gayab ho jaata hai, lekin laal serial slice apni jagah rehta hai. Bar laal block se chhota nahi ho sakta. Woh laal block hi wall hai — isko ghoorte raho.

Step 7 — Speedup curve flatten hoti hai (woh picture jo war decide karti hai)

KYA. Speedup $S$ ko vertical axis par aur cores ki sankhya $N$ ko horizontal axis par, $P$ ki kuch values ke liye plot karo.

KYUN. Ek curve woh dikhata hai jo ek akela number chhupa leta hai: diminishing returns. Shuruat ke cores bahut help karte hain; baad ke cores line ko mushkil se hilate hain. Shape hi argument hai.

PICTURE. Har curve badhti hai phir height $\frac{1}{1 - P}$ par ek horizontal ceiling mein flatten ho jaati hai ( $P = 0.95$ ke liye laal dashed line). High- $P$ workloads (matrix math, SIMD-friendly, top ke paas) climb karte rehte hain — woh manycore GPUs par jaate hain. Low- $P$ workloads jaldi flatten ho jaate hain — woh multicore par rehte hain.

Step 8 — Degenerate corners (koi case kabhi bina dikhaye mat chhodna)

KYA. Teen extreme inputs check karo taaki formula kabhi surprise na kare. Crucial yeh hai ki hum inke liye naye formulas nahi banate — har corner Step 5 ke wahi $S = \frac{1}{( 1 - P ) + P / N}$ mein $P$ ya $N$ ki ek value plug karna hai.

KYUN. Ek law jise aap apne edges par sanity-check nahi kar sakte woh ek aisa law hai jis par aap trust nahi karte. Har corner ko ek aisa jawaab dena chahiye jo sahi lagta ho — aur har ek ko general expression se nikalna chahiye, koi special rule nahi.

PICTURE. Teen mini-bars: fully serial (koi shrink nahi), fully parallel (almost nothing tak shrinks), aur single core (koi change nahi).

Case	Inputs	$S = \frac{1}{( 1 - P ) + P / N}$ mein plug karo	Meaning
Fully serial	$P = 0$	$\frac{1}{( 1 - 0 ) + 0/ N} = \frac{1}{1} = 1$	Koi parallel part nahi → cores kuch nahi karte. Speedup $= 1 \times$ .
Fully parallel	$P = 1$	$\frac{1}{0 + \frac{1}{N}} = N$	Perfect scaling → $N$ cores $N \times$ dete hain. GPU ka sapna.
Single core	$N = 1$	$\frac{1}{( 1 - P ) + \frac{P}{1}} = \frac{1}{1} = 1$	Ek core = baseline. Speedup $= 1 \times$ by definition. ✓

Ghaur karo ki teeno answers ek ek general formula se nikle — extremes $P = 0$ aur $P = 1$ legal inputs hain, exceptions nahi.

Ek picture ka summary

Upar ki sab cheez — bar, split, shrink, ceiling — ek single frame mein.

Recall Feynman retelling — plain words mein wapas kaho

Ek program time ki ek bar hai. Ise colour karo: laal part ek-step-at-a-time chalna chahiye, kaala part split ho sakta hai. Use $N$ cores do — sirf kaala part sirkta hai, apne size ka $1/ N$ ho jaata hai (ideally, perfect equal splitting aur zero overhead assume karte hue); laal part hilne se mana karta hai. Hum sab kuch original bar ke relative measure karte hain ( $T_{orig} = 1$ ), isliye speedup $S$ sirf purani bar (=1) divide by nayi, shrunken bar hai, jo $\frac{1}{( 1 - P ) + P / N}$ deta hai. Ab aur aur cores imagine karo: $P / N$ negligibly small ho jaata hai, kaala part poora gayab ho jaata hai, lekin laal part abhi bhi wahin hai — toh best aap kabhi bhi kar sakte ho woh hai $\frac{1}{1 - P}$ , purely is baat se set hota hai ki kitna laal hai. Use plot karo aur har curve us ceiling mein flatten ho jaata hai. Agar aapka code mostly laal hai (serial, branchy), curve instantly flatten hoti hai, toh kuch bahut fast cores kharido — yeh multicore hai. Agar aapka code almost sab kaala hai ( $P \to 1$ , jaise matrix math), curve hamesha ke liye climb karti hai, toh haazaron tiny cores kharido — yeh manycore hai. Poora multicore-vs-manycore choice sirf yeh hai: aapki bar mein kitna laal hai?

Recall Quick self-test

$P = 0.9$ aur $N = 8$ ke saath, $S$ kya hai? ::: $\frac{1}{0.1 + 0.9/8} = \frac{1}{0.2125} \approx 4.71 \times$ $P = 0.9$ ke saath, $N \to \infty$ par ceiling kya hai? ::: $\frac{1}{1 - 0.9} = 10 \times$ Laal (serial) block kyun kabhi nahi sirkta? ::: Sirf ek worker ise chala sakta hai, ek step at a time — kuch split karne ke liye hai hi nahi, isliye $N$ kabhi $(1 - P)$ term mein appear nahi karta. Kaun sa curve shape chillata hai "manycore GPU banao"? ::: Woh jo climbing rehta hai ( $P = 1$ ke paas), taaki har added core abhi bhi real speedup kamaata rahe. Ek assumption ka naam lo jo real speedup ko formula se worse banata hai. ::: Koi bhi: imperfect load-balancing, thread-startup overhead, ya communication/coherence cost — sab yahan zero assume kiye gaye hain.