Dataflow architectures: Question bank — Hinglish deep dive

6.5.9 · D5 · Hardware › Advanced & Emerging Architectures › Dataflow architectures

Intuition Is page ko kaise use karein

Neeche har ek item ek trap hai — ek aisi jagah jahan Dataflow architectures ke baare mein ek natural lekin galat intuition aapko cliff se gira deta hai. Prompt padho, answer ko cover karo, koi position zor se lo, phir reveal karo. Agar tumhara reasoning match karta hai (sirf haan/naa nahi), tab samjha. Agar sirf verdict match kiya, toh lucky rhe — reasoning dobara padho.

Pehle, woh do words jo yahan almost har answer decide karte hain:

Ek token ek packet hai jo ek value carry karta hai (aur dynamic dataflow mein, ek tag — ek label jo kehta hai "main program ke kis run se belong karta hoon"). Yeh ek node produce karta hai aur agli node consume karti hai.
Firing rule is machine ka ek hi kanoon hai: ek node usi waqt run hoti hai jab saare input edges par tokens hon (aur dynamic dataflow mein, tokens jinke tags match karein). Kuch aur nahi — na clock order, na program counter — decide karta hai ki node kab run hogi.

True ya false — justify karo

Har prompt ek statement hai. True/false decide karo aur kyun bolo — wajah hi asli answer hai.

Dataflow mein bilkul koi execution order nahi hota, isliye results kisi bhi order mein aa sakte hain.

False. Koi program-counter order nahi hota, lekin ek strict order zaroor hoti hai: data dependencies. Ek node jiske inputs ready nahi hain physically fire nahi kar sakti, isliye dependent results hamesha un results ke baad aate hain jinpe woh depend karte hain.

Kyunki koi program counter nahi hai, ek dataflow machine nahi jaanti ki program kab khatam hua.

False. Program ek graph hai jisme output nodes hain; "khatam" ka matlab hai ki final output node(s) fire ho gayi hain aur aur koi token move nahi kar sakta. PC ka na hona sequencing ko hata deta hai, completion ko nahi.

Static aur dynamic dataflow mein sirf itna fark hai ki woh kitni fast run karte hain.

False. Asli fark token capacity per edge aur re-entrancy mein hai: static mein ek edge par zyada se zyada ek token ho sakta hai (overlapping instances nahi); dynamic mein tokens ko tag kiya jaata hai taaki same subgraph ki kai concurrent copies coexist kar sakein. Speed ek consequence hai, definition nahi.

Dynamic dataflow mein, matching values lekin alag tags wale do tokens milke ek node ko fire kar sakte hain.

False. Firing ke liye matching tags chahiye, matching values nahi. Alag tags matlab alag runs (iterations/invocations); unhe pair karna alag contexts ka data mix kar dega aur garbage produce karega.

Koi bhi expression sirf zyada processing units add karke zyada parallel run ho sakta hai.

False. Parallelism critical path se cap hoti hai — dataflow graph mein dependent nodes ki sabse lambi chain. Extra units ek aisi chain ko chota nahi kar sakte jahan har node ko pichli node ka output chahiye.

Do nodes jo kisi bhi edge se connected nahi hain woh hamesha ek saath fire ho sakti hain.

True (hardware diya ho toh). Unke beech koi edge nahi matlab na woh doosre ka input hai, isliye unke firing rules independent hain — yahi wajah hai ki dataflow parallelism "for free" expose karta hai.

Ek token kisi ordinary circuit mein wire par hold hone wale voltage ki tarah behave karta hai.

False. Wire ka voltage persist karta hai aur kaafi baar re-read ho sakta hai; ek token ek baar produce hota hai aur ek baar consume hota hai. Matching unit ko node fire hone se pehle input tokens ka complete set collect karna hota hai, phir woh tokens chale jaate hain.

Out-of-order superscalar CPUs Von Neumann machines hain, isliye unka dataflow se koi lena-dena nahi.

False. Unka Out-of-Order Execution core ek chota hidden dataflow engine hai: reservation stations operands (tokens) ka intezaar karte hain aur ready hone par fire karte hain — essentially PC-based front end ke andar wrapped tagged-token matching.

Agar ek static dataflow graph mein har edge abhi ek token hold kar rahi hai, toh machine deadlock ho gayi hai.

Generally False. Ek full edge ka matlab sirf itna hai ki producer aage bhaag gaya; downstream nodes woh tokens consume karenge aur fire hone par edges free karenge. Deadlock tab hi hota hai jab edges ka ek cycle ho jisme har edge doosre ka intezaar kar rahi ho.

Error dhundho

Har item mein ek claim ya reasoning step hai jisme koi flaw hai. Flaw ka naam lo aur use correct karo.

"a=x+y aur b=p+q ko parallelize karne ke liye, ek dataflow compiler ko batana padega ki woh independent hain."

Error: independence batai nahi jaati, woh dikhti hai. Kyunki a aur b koi producer/consumer edge share nahi karte, unke firing rules alag-alag satisfy hote hain — graph structure already independence encode karta hai.

"Ek loop mein tags drop kar sakte hain jab tak har iteration shuru hone se pehle khatam ho."

Error: woh ordering force karna saara benefit hi khatam kar deta hai — iterations ke across pipeline overlap. Tags isliye exist karte hain taaki iterations overlap kar sakein safely; unhe serialize karna sirf disguise mein Von Neumann hai.

"Ek - node x - z mein do baar fire hogi agar x aur z alag-alag times par aayein."

Error: arrival time extra firings cause nahi karta. Node tab tak wait karta hai jab tak dono input tokens present na hon, phir ek baar fire karta hai, dono consume karke. Staggered arrival sirf firing mein delay karta hai.

"(x+y)*(x-z) mein multiply ko x do baar chahiye, isliye x ek hi token hona chahiye jo dono adders share karein."

Error: ek token fire hone par consume ho jaata hai, isliye ek single x token do nodes ko feed nahi kar sakta. Graph ko x duplicate karna padega (ek fan-out / copy node har consumer ko ek x token emit karta hai).

"Dynamic dataflow ko matching hardware ki zarurat nahi kyunki tags firing automatic bana dete hain."

Error: tags key hain, mechanism nahi. Ek matching store actively waiting tokens ko hold karta hai aur equal tag wale partner ko dhundhta hai; iske bina, tagged tokens kabhi pair nahi hote.

"Ek dataflow machine mein program counter add karne se woh tez ho jaayegi kyunki use ek clear order mil jaayega."

Error: ek PC woh sequential bottleneck dobara thop deta hai jise dataflow hatane ke liye banaya gaya tha, independent nodes ko serialize karke. Yeh exposed parallelism ko slow karega, help nahi karega.

"Ek dataflow graph mein cycles freely ho sakti hain kyunki Directed Acyclic Graph (DAG) sirf ek special case hai."

Error: acyclic form ek single straight-line computation describe karta hai. Loops controlled cycles introduce karte hain, lekin unhe extra machinery chahiye (tags, ya explicit control nodes) — aap cycles "freely" add nahi kar sakte bina is risk ke ki tokens ka koi valid partner na ho.

Why questions

Answer mein mechanism dena zaroori hai, sirf phenomenon restate nahi karna.

Dataflow koi special "parallel for" annotation ke bina parallelism expose kyun karta hai?

Kyunki independence ek structural property hai: unconnected nodes ke independently-satisfiable firing rules hote hain, isliye hardware unhe saath run karta hai jis pal unke inputs exist karte hain. Dekho Instruction-Level Parallelism — dataflow uski natural limit hai.

tan-style "instruction address order" yahan exist kyun nahi karta, phir bhi program sahi result kyun compute karta hai?

Sahi partial order akele data dependencies se enforce hoti hai: ek consumer ko literally koi input nahi milta jab tak uska producer fire na kare. Address order hamesha us par redundant extra ordering thi.

Dynamic dataflow mein har token ko tag kyun carry karna padta hai, hardware sirf arrival order use kyun nahi karta?

Arrival order unreliable hai — ek fast iteration-2 token slow iteration-1 token ko overtake kar sakta hai. Tag ek identity hai jo reordering mein survive karti hai, isliye pairing correct rehti hai chahe pehle kaun bhi aaye.

Loop-Level Parallelism tagged dataflow mein sasta kyun hai lekin Von Neumann CPU mein painful?

Tagging har iteration ko tokens ka alag-identified set banata hai, isliye overlapping iterations tag se self-organize ho jaati hain. Ek PC-based CPU ko wahi overlap fake karne ke liye independence prove karni padti hai, registers rename karne padte hain, aur hazards track karne padte hain.

Ek systolic array "data-driven" kyun maana jaata hai dataflow ki tarah, jabki uska schedule fixed hota hai?

Data abhi bhi computation ko array mein push karta hai jaise woh arrive karta hai, cell-by-cell, bina kisi program counter ke jo instructions fetch kare. Regular fixed rhythm "fire when data is present" ka ek specialized, hardwired version hai.

Artificial ordering hatane se results non-deterministic kyun nahi ho jaate?

Ek node jo value compute karta hai woh sirf is par depend karta hai ki woh kaunse tokens consume karta hai, aur dependencies woh fix karte hain. Timing run to run vary kar sakti hai, lekin final values graph ke through pin hoti hain.

Edge cases

Boundary aur degenerate scenarios — woh jo exam-setters ko pasand hain.

Ek node ke do inputs hain lekin ek input edge ko kabhi token nahi milta. Kya hota hai?

Node kabhi fire nahi hoti; woh forever wait karti hai. Yeh ek genuine dataflow stall/deadlock hai, jo missing producer ki wajah se hota hai, na ki kisi scheduler choice ki wajah se.

Ek operation node ko bilkul koi inputs nahi chahiye (jaise ek constant source). Woh kab fire karta hai?

Uski firing rule trivially satisfied hai (required inputs ka empty set), isliye woh startup par immediately fire ho sakta hai, graph ko ek constant token se seed karta hua.

Ek + node ko same tag wale do tokens milte hain lekin out of order (doosra operand pehle). Kya sum badal jaata hai?

Nahi. Matching tag se hoti hai, arrival order se nahi; jab ek baar dono same-tag tokens present hoon toh node ek baar correct pair ke saath fire karta hai. Addition ki commutativity bhi operand order ko irrelevant banati hai yahan.

Static dataflow mein, ek producer doosra token ek aisi edge par emit karne ki koshish karta hai jisme pehle se ek token hai. Kya hona chahiye?

Producer ko stall (back-pressure) karna padega jab tak consumer edge drain na kar de, kyunki ek static edge mein zyada se zyada ek token hota hai. Yeh built-in flow control hai jise dynamic dataflow tags ke saath relax karta hai.

Ek loop zero baar run karta hai (n = 0). Ek dataflow loop ise kaise handle karta hai?

Loop ke control/merge nodes initial value ko sidha output tak route kar dete hain bina kisi body firing ke. "Zero iterations" sirf ek aisi firing rule hai jo body node ko kabhi enable nahi karti.

Do independent subgraphs khatam hote hain, lekin poore program mein ek output node hai jo dono se fed hai. Output kab fire karta hai?

Tabhi jab dono feeding tokens present hon — output baad wale dono mein se ek ka intezaar karta hai, yani slower branch ke through critical path completion time determine karti hai.

Ek tagged token ka matching tag wala partner kabhi nahi aata (lost/omitted). Kya effect hota hai?

Woh token indefinitely matching store mein baitha rehta hai, ek silent partial-match leak — dynamic dataflow mein ek real hazard jise hardware bound karna chahiye (limited matching store) warna program stall kar jaata hai.

Recall Kisi bhi dataflow claim ke liye one-line litmus test

Puchho: "Kya yeh tab bhi true hoga agar main sirf yeh rule rakhun 'fire when all matching-tag inputs are present'?" Agar claim ko true hone ke liye clock, PC, ya arrival order chahiye, toh yeh ek trap hai.

Connections

Dataflow architectures — parent topic jinhe yeh traps drill karte hain.
Von Neumann architecture — sequential model jo zyaatar misconceptions mein chhupchhupa ke wapas aata hai.
Out-of-Order Execution — real CPUs ke andar hidden tagged-token matching.
Instruction-Level Parallelism — dataflow as its theoretical limit.
Loop-Level Parallelism — kyun tags sasta iteration overlap unlock karte hain.
Systolic Arrays — data-driven execution ka ek fixed-schedule cousin.
Directed Acyclic Graph (DAG) — loop-free dataflow ke peeche ki structure.