Heterogeneous computing concepts — Hinglish notes

6.1.12 · Hardware › Parallelism & Multicore

Intuition Core Idea

Heterogeneous computing ka matlab hai alag-alag types ke processors ko ek hi system mein use karna, jahan har processor alag tasks ke liye optimize hota hai. Isse ek kitchen ki tarah socho: tum blender se bread slice nahi karte, aur knife se smoothie nahi banate. CPU tera Swiss Army knife hai (versatile, sequential tasks), GPU tera industrial food processor hai (massive parallel tasks), aur specialized accelerators (TPUs, FPGAs) woh single-purpose tools hain jaise rice cooker.

WHY? Koi bhi ek processor architecture sabhi workloads ke liye optimal nahi hoti. CPUs complex control flow aur latency-sensitive tasks mein excel karte hain. GPUs data-parallel operations mein excel karte hain. Inhe combine karke hum specific workloads ke liye orders of magnitude better performance-per-watt paate hain.

Computing "Heterogeneous" Kab Hoti Hai?

Key characteristics:

Different processor types (CPU + GPU, CPU + FPGA, CPU + DSP, etc.)
Asymetric capabilities (sirf alag speeds nahi, balki alag strengths)
Task partitioning (processor ki strengths ke basis par kaam divide karna)
Explicit data movement processor memories ke beech (aksar bottleneck hota hai)

WHAT — yeh homogeneous multicore se kaise alag hai?

Homogeneous: 8 identical CPU cores, sab same instruction set run karte hain
Heterogeneous: 4 CPU cores + 1 GPU with 2048 CUDA cores + 1 Neural Processing Unit

Hardware Architecture

CPU: The Control Master

Design philosophy: Individual tasks ki latency ko optimize karo

HOW yeh achieve karta hai:

Large caches (MB range) → memory access time kam karo
Complex out-of-order execution → instruction dependencies chhupao
Branch prediction → control flow par speculate karo
Thode powerful cores (typically 4-64)

Best for:

Sequential algorithms
Irregular memory access patterns
Complex control flow (bahut saare if/else, function calls)
Operating system tasks, coordination

GPU: The Throughput Engine

Design philosophy: Bahut saare parallel tasks ka throughput optimize karo

HOW yeh achieve karta hai:

Hazaron simple cores (ALUs)
Har core ke paas small caches
SIMT execution model (Single Instruction, Multiple Threads)
Massive memory bandwidth (hundreds of GB/s)

Best for:

Data-parallel operations (millions of data points par same operation)
Regular memory access patterns (coalesced reads/writes)
Graphics rendering, matrix operations, simulations

Specialized Accelerators

Accelerators fixed-function ya configurable hardware hote hain jo ek class of problems ke liye design hote hain.

Types:

TPU (Tensor Processing Unit): Neural networks ke liye matrix multiply-accumulate operations
FPGA (Field-Programmable Gate Array): Custom datapaths ke liye reconfigurable logic blocks
DSP (Digital Signal Processor): Filtering, FFT, convolution ke liye optimize
Crypto accelerators: AES encryption, SHA hashing

WHY yeh exist karte hain: Narrow domains ke liye, hardwired logic general-purpose cores se 10-100x zyada energy-efficient hoti hai.

Programming Model Ka Challenge

Memory Hierarchy Mismatch

Total execution time: $T_{t o t a l} = T_{C P U \to GP U} + T_{co m p u t e_GP U} + T_{GP U \to C P U}$

WHY yeh matter karta hai: Agar $T_{co m p u t e_GP U}$ chhota hai, toh data transfer dominate kar leta hai!

Break-even point ki derivation:

Let:

$B$ = PCIe bandwidth (GB/s)
$D$ = data size (GB)
$F_{C P U}$ = CPU FLOPS
$F_{GP U}$ = GPU FLOPS
$W$ = work (total FLOPS needed)

CPU alone par time: $T_{C P U} = \frac{W}{F _{C P U}}$

Heterogeneous system par time: $T_{h e t er o} = \frac{2 D}{B} + \frac{W}{F _{GP U}}$

(Factor of 2 isliye kyunki data CPU→GPU→CPU jaata hai)

Break-even jab $T_{h e t er o} < T_{C P U}$ : $\frac{2 D}{B} + \frac{W}{F _{GP U}} < \frac{W}{F _{C P U}}$

$\frac{2 D}{B} < W (\frac{1}{F _{C P U}} - \frac{1}{F _{GP U}})$

WHY THIS STEP? Hum data movement cost ko left side par isolate karte hain. Right side GPU ka computational advantage hai.

$W > \frac{2 D \cdot F _{C P U} \cdot F _{GP U}}{B ( F _{GP U} - F _{C P U} )}$

Interpretation: Transfer overhead overcome karne ke liye data size (D) ke relative enough work (W) chahiye. Isse arithmetic intensity kehte hain.

1 GB data transfer: $T_{t r an s f er} = \frac{2 \times 1}{32} = 0.0625 seconds$

Break-even ke liye, GPU compute time kam se kam 0.0625s bachaye:

Work needed: $W > \frac{2 \times 1 \times 10}{32 ( 10 - 1 )} = \frac{20}{288} \approx 0.069 TFLOPS$

$W > 69 GFLOPS$

WHY? Agar task mein 69 billion floating-point operations hain, toh GPU itna time bachata hai ki transfer cost justify ho jaaye.

Arithmetic intensity: $\frac{W}{D} = \frac{69 GFLOPS}{1 GB} = 69 FLOP/byte$

Practical insight: Matrix-matrix multiply (O(n³) work, O(n²) data) GPUs ke liye great hai. Vector addition (O(n) work, O(n) data) terrible hai.

Task Partitioning Strategies

Teen models:

Offload model: CPU setup/control karta hai, GPU compute kernels karta hai, CPU post-processing karta hai
Pipelined model: CPU stage 1 → GPU stage 2 → CPU stage 3, alag data ko overlap karte hue
Collaborative model: CPU aur GPU ek hi problem ke alag parts par simultaneously kaam karte hain

Step-by-step with WHY:

CPU disk se image1 padhta hai → CPU ke paas file system access hai
CPU image 1 ko GPU par transfer karta hai → GPU ko data VRAM mein chahiye
GPU image 1 par filters apply karta hai → Massively parallel pixel operations
CPU image 2 padhta hai (step 3 ke saath overlap) → Transfer latency chhupao
GPU processed image 1 CPU ko return karta hai → CPU disk par likhega
CPU image 1 disk par likhta hai (GPU ke image 2 process karne ke saath overlap)

WHY pipelined? Har stage dusron ke saath overlap karta hai. Total time ≈ max(read, transfer, compute, write) ×1000, unka sum nahi.

Pipeline efficiency ka formula:

Agar stages $t_{1}, t_{2}, .., t_{k}$ time lete hain aur hum $n$ items process karte hain:

Sequential time: $n \times (t_{1} + t_{2} + ... + t_{k})$

Pipelined time: $(t_{1} + t_{2} + ... + t_{k}) + (n - 1) \times max (t_{1}, .., t_{k})$

WHY? Pehla item full latency pay karta hai, phir hum slowest stage ki rate se chalte hain.

Speedup: $S = \frac{n \times \sum t _{i}}{( \sum t _{i} ) + ( n - 1 ) \times m a x ( t _{i} )} \approx \frac{\sum t _{i}}{m a x ( t _{i} )} as n \to \infty$

Heterogeneous Systems Mein Amdahl's Law

Original Amdahl's Law homogeneous speedup assume karta hai. Hume isse extend karna hoga.

Let:

$f_{s}$ = code ka woh fraction jo serial hai (CPU-only)
$f_{p}$ = woh fraction jo parallelizable hai (GPU use kar sakta hai)
$S_{GP U}$ = parallel work ke liye GPU ka CPU ke upar speedup
$f_{s} + f_{p} = 1$

Scratch se derivation:

Original execution time (CPU only): $T_{0} = 1$ (normalized)

Naya execution time:

Serial part: $f_{s} \times 1 = f_{s}$ (koi speedup nahi)
Parallel part: $\frac{f _{p}}{S _{GP U}}$ ( $S_{GP U}$ times faster chalti hai)
Data transfer overhead: $t_{x f er}$ per kernel launch

$T_{h e t er o} = f_{s} + \frac{f _{p}}{S _{GP U}} + t_{x f er}$

WHY THIS STEP? Serial work unaffected rehta hai. Parallel work GPU se benefit leta hai. Lekin hum transfer tax pay karte hain.

Overall speedup: $S_{o v er a l l} = \frac{1}{f _{s} + \frac{f _{p}}{S _{GP U}} + t _{x f er}}$

Critical insight: Chahe $S_{GP U} = \infty$ ho, speedup $\frac{1}{f _{s} + t _{x f er}}$ se bounded hai

$S_{o v er a l l} = \frac{1}{0.05 + \frac{0.95}{50} + 0.02} = \frac{1}{0.05 + 0.019 + 0.02} = \frac{1}{0.089} \approx 11.2 \times$

WHY sirf 11x jab GPU 50x faster hai?

5% serial bottleneck
2% transfer overhead
Yeh fixed costs dominate karte hain!

Kya hoga agar hum transfer overhead eliminate kar dein (unified memory)? $S_{n e w} = \frac{1}{0.05 + 0.019} = 14.5 \times$

Transfers eliminate karne se sirf 3.3x improvement! Asli killer woh 5% serial code hai.

Common Heterogeneous Patterns

Map Pattern (Embarrassingly Parallel)

Definition: Har element par independently same function apply karna.

CPU code:

for (int i = 0; i < N; i++) {
    output[i] = f(input[i]);
}

GPU kyun jeetta hai: Har iteration independent hai, hazaron threads ke liye perfect.

Arithmetic intensity: Low (O(1) work per byte jab tak f complex na ho).

Reduce Pattern (Parallel with Coordination)

Definition: Array elements ko associative operator se combine karna (sum, max, etc.)

Sequential: $r es u l t = a_{0} \oplus a_{1} \oplus ... \oplus a_{n}$

Parallel tree reduction:

Work/span ki derivation:

Work (total operations): Phir bhi $n - 1$ operations (isse reduce nahi kar sakte)

Span (critical path):

Level 1: $n /2$ pairs parallel mein combine hote hain → depth 1
Level 2: $n /4$ pairs combine → depth 2
...
Level $lo g_{2} n$ : final combine

$Span = lo g_{2} n$

WHY? Har level data ko half karta hai, ek step leta hai.

$p$ processors ke saath speedup: $S = \frac{n}{l o g _{2} n + overhead}$

GPU par: Levels ke beech synchronization ki wajah se overhead zyada hota hai. Warp-level primitives use karna better hai.

GPU (tree reduction):

1024 threads per block, 976 blocks ke saath kernel launch karo
Har thread 1024 elements sum karta hai → 976 partial sums
CPU par 976 sums reduce karo (kaafi chhota)
Time: ~0.5ms GPU compute + 0.5ms transfer = 1ms total

Speedup: 3x (great nahi kyunki low arithmetic intensity hai)

WHY zyada fast nahi? Har element ek baar padha jaata hai, ek baar add hota hai. 1 FLOP per 4 bytes ka ratio (float assume karke). PCIe transfer time dominate karta hai.

Scan Pattern (Prefix Sum)

Definition: Output[i] = input[0] ⊕ input[1] ⊕ ... ⊕ input[i]

Applications: Stream compaction, radix sort, resource allocation

Parallel algorithm (work-efficient):

Step 1 - Upsweep (tree build karo):

for d = 0 to log₂(n) - 1:
    for each k = 0 to n/(2^(d+1)) - 1 in parallel:
        idx = (k+1) * 2^(d+1) - 1
        a[idx] = a[idx - 2^d] + a[idx]

WHY THIS STEP? Partial sums ka binary tree banao, levels upar jaate hue.

Step 2 - Downsweep (sums propagate karo):

a[n-1] = 0  // identity
for d = log₂(n) - 1 down to 0:
    for each k in parallel:
        idx = (k+1) * 2^(d+1) - 1
        temp = a[idx - 2^d]
        a[idx - 2^d] = a[idx]
        a[idx] = a[idx] + temp

WHY THIS STEP? Accumulated sum neeche propagate karo, inclusive scan property maintain karte hue.

Work: $O (n)$ - sequential jaisa hi! Span: $O (lo g n)$ - logarithmic depth GPU advantage: Extra work ke bina parallelism exploit karta hai.

Programming Models & APIs

Popular models:

CUDA/HIP: Low-level, explicit control (NVIDIA/AMD GPUs)
OpenCL: Cross-platform, vendor-neutral
OpenMP offload: Pragma-based, implicit transfers
SYCL: C++ template-based, single-source
Vulkan Compute: Compute shaders wala Graphics API

Worked example CUDA Workflow (Conceptual)

Step 1 - Device memory allocate karo:

float *d_input, *d_output;
cudaMalloc(&d_input, N * sizeof(float));
cudaMalloc(&d_output, N * sizeof(float));

WHY? GPU ke paas separate VRAM hai, explicitly allocate karna padta hai.

Step 2 - Data device par copy karo:

cudaMemcpy(d_input, h_input, N*sizeof(float), 
           cudaMemcpyHostToDevice);

WHY? PCIe bus par transfer.

Step 3 - Kernel launch karo:

int threads_per_block = 256;
int blocks = (N + 255) / 256;
kernel<<<blocks, threads_per_block>>>(d_input, d_output, N);

WHY THIS SYNTAX? <<<blocks, threads>>> grid dimensions specify karta hai. GPU in threads ko schedule karta hai.

Step 4 - Result wapas copy karo:

cudaMemcpy(h_output, d_output, N*sizeof(float),
           cudaMemcpyDeviceToHost);

Step 5 - Memory free karo:

cudaFree(d_input);
cudaFree(d_output);

Total overhead: Allocations + 2 transfers + kernel launch latency. Isliye arithmetic intensity matter karti hai!

Power Efficiency: The Real Win

Energy advantage ki derivation:

Let:

$P_{C P U}$ = CPU power (watts)
$P_{GP U}$ = GPU power jab active hai (watts)
$P_{i d l e}$ = GPU idle power (watts)
$T_{C P U}$ = CPU par time
$T_{GP U}$ = GPU par time (compute only)
$T_{x f er}$ = transfer time

CPU par energy: $E_{C P U} = P_{C P U} \times T_{C P U}$

Heterogeneous system par energy: $E_{h e t er o} = P_{C P U} \times (T_{x f er} + T_{C P U_ser ia l}) + P_{GP U} \times T_{GP U} + P_{i d l e} \times T_{x f er}$

WHY THIS FORM? CPU transfers aur serial code ke dauran active rehta hai. GPU compute ke dauran active rehta hai. GPU transfers ke dauran idle rehta hai.

Pure parallel workload ke liye ( $T_{C P U_ser ia l} = 0$ ):

Agar $T_{GP U} = \frac{T _{C P U}}{S _{GP U}}$ (speedup $S_{GP U}$ ):

$E_{h e t er o} = P_{C P U} \times T_{x f er} + P_{GP U} \times \frac{T _{C P U}}{S _{GP U}} + P_{i d l e} \times T_{x f er}$

Energy efficiency gain: $η = \frac{E _{C P U}}{E _{h e t er o}} = \frac{P _{C P U} \times T _{C P U}}{( P _{C P U} + P _{i d l e} ) \times T _{x f er} + P _{GP U} \times \frac{T _{C P U}}{S _{GP U}}}$

WHY IMPORTANT? Data centers mein, energy cost hardware cost se zyada dominate karti hai!

GPU Setup:

NVIDIA A100, 400W TDP, 10 TFLOPS (20× faster)
Time: 0.5 hours + 5 min overhead
Energy: 400W × 2100s = 0.84 MJ = 0.23 kWh

Energy saving: 85%!

WHY? GPU zyada power use karta hai, lekin 20× faster khatam karta hai, aur zyada time idle rehta hai. Total energy 6.5× kam hoti hai.

Cost: $0.12/ k W h p a r, C P U k a$ 0.18 aur GPU ka $0.03 p er e p oc h l a g t ahai .1000 e p oc h s m e in$ 150 bachao.

Advanced Concepts

Heterogeneous Systems Mein Cache Coherence

Problem: CPU aur GPU ke separate memory spaces hain (disaggregated memory). Agar dono same data access karein, toh copies diverge ho sakti hain.

Solutions:

Manual coherence: Programmer ensure karta hai ki writes ke baad transfers hon
Unified memory: Hardware/driver coherence maintain karta hai (CUDA unified memory)
Cache-coherent interconnect: AMD Infinity Fabric, Intel CXL

Trade-off: Automatic coherence latency add karta hai (coherence protocol traffic).

Dynamic Task Scheduling

Challenge: Runtime mein CPU vs GPU kaise decide karein jab workload unknown ho?

Approach - Work stealing:

CPU aur GPU dono ek shared queue se tasks lete hain
GPU tasks leta hai agar queue badi hai (overhead amortize karo)
CPU tasks leta hai agar queue chhoti hai (low latency)

Threshold ka formula:

GPU par execute karo agar: $Queue size > \frac{T _{x f er} \times F _{GP U}}{S _{GP U} - 1}$

WHY? Transfer cost overcome karne ke liye enough work chahiye.

FPGA vs GPU Trade-offs

Aspect	FPGA	GPU
Latency	Microseconds (hardwired datapath)	Milliseconds (kernel launch)
Throughput	Lower peak	Higher peak
Power	10-50W	200-400W
Flexibility	Reconfigurable (minutes)	Fully programmable (instant)
Best for	Fixed pipelines, low-latency	Data-parallel, training

Example: High-frequency trading FPGAs use karta hai (10μs latency matter karta hai). AI training GPUs use karta hai (throughput matter karta hai).

Galtiyan & Misconceptions

Yeh sahi kyun lagta hai: GPUs ke paas zyada cores aur higher FLOPS hain.

Fix: GPUs specific patterns mein excel karte hain (data parallelism, high arithmetic intensity). Serial code, complex control flow, ya chhote datasets ke liye CPU faster hai. Transfer overhead GPU ko parallel work ke liye bhi slower bana sakta hai agar dataset chhota ho.

Litmus test: Kya tumhara workload hai:

Massively parallel? (Haan zaroori)
Regular memory access? (Haan zaroori)
High arithmetic intensity (>10 FLOP/byte)? (Haan zaroori)
Large dataset (>10MB)? (Haan zaroori)

GPU jeet guaranteed karne ke liye chaaron sach hone chahiye.

Yeh sahi kyun lagta hai: Zyada parallelism matlab zyada speed hona chahiye.

Fix:

Amdahl's Law: Serial portions speedup limit karte hain
Memory bandwidth: Agar memory-bound hai, toh cores data ka wait karte idle baithte hain
Occupancy: GPU ko latency hide karne ke liye har core par bahut threads chahiye (full utilization ke liye 2048 nahi, 10,000+ threads chahiye)
Coordination overhead: Threads ke beech synchronization cost add karta hai

Reality: Well-suited problems ke liye 10-100× speedup typical hai, 1000× nahi.

Yeh sahi kyun lagta hai: Unified memory explicit transfers ko abstract kar deta hai.

Fix: Unified memory phir bhi PCIe par data move karta hai, bas automatically. Tum phir bhi latency pay karte ho! Isse bhi bura, page faults (jab GPU CPU page touch karta hai) explicit batched transfers se slower ho sakte hain. Unified memory convenient hai, free nahi.

Best practice: Control retain karne ke liye cudaMemPrefetchAsync se large blocks prefetch karo.

Yeh sahi kyun lagta hai: FPGAs kam power lete hain aur per-algorithm optimize ho sakte hain.

Fix:

Development time: FPGA design mein months lagte hain (RTL coding). GPU kernel mein days lagte hain.
Flexibility: FPGA logic change karne ke liye resynthesis chahiye (minutes-hours). GPU instant recompile karta hai.
Peak performance: Modern GPUs data-parallel tasks ke liye higher throughput rakhte hain.

FPGAs tab use karo jab: Latency critical ho, power scarce ho, aur algorithm stable ho (aksar nahi badlega).

Connections

CPU Architecture and Pipeline: CPU design samajhna motivate karta hai ki GPUs alag kyun architect hote hain
Memory Hierarchy and Caching: Explain karta hai ki heterogeneous systems mein data movement kyun dominate karta hai
Parallel Programming Models: Thread-level parallelism concepts GPU thread blocks tak extend hote hain
Amdahl's Law and Scalability: Directly heterogeneous speedup analysis par apply hota hai
Power and Energy Optimization: Heterogeneous computing ka primary advantage
SIMD and Vector Processing: GPU SIMT, SIMD principles ka evolution hai
DMA and I/O Controllers: Similar asynchronous data transfer concepts
Rofline Performance Model: Tool for analyzing if workload is compute- or memory-bound on accelerators

Recall Ek 12-Saal ke Bacche Ko Samjhao

Imagine karo tum homework kar rahe ho. Kuch problems mein bahut zyada sochna padta hai (jaise koi tricky word problem) — yahi tumhara brain (CPU) best karta hai. Lekin kuch problems mein bas ek hi simple kaam bar bar karna hota hai, jaise ek hazar squares ek hi rang se color karna. Uske liye tum 10 doston (GPU cores) ko crayons de sakte ho aur 10× jaldi khatam kar sakte ho!

Heterogeneous computing ka matlab hai smart rehna — kab tum khud sochna karo (CPU) aur kab apne doston ko simple kaam do (GPU). Trick yeh hai: agar kaam explain karne aur crayons baantne mein khud karne se zyada time lage, toh yeh worth it nahi! Isliye hum GPU doston ko sirf BADE kaam dete hain jisme bahut repetition ho.

Kuch special tools (accelerators) waise hote hain jaise ek-kaam-ke-machines — bread slicer sirf bread slice karta hai, lekin usme sabse fast hota hai. Yehi idea TPUs ka AI ke liye aur FPGAs ka specific jobs ke liye hai.

Flashcards

#flashcards/hardware

Heterogeneous computing kya hai? :: Ek computing architecture jo do ya zyada alag types ke processors (jaise CPU + GPU, CPU + FPGA) use karti hai alag capabilities ke saath, jo task partitioning karke har processor ki strengths ke basis par milkar kaam karte hain.

CPUs ke upar GPUs ka primary advantage kya hai?

GPUs data-parallel tasks ke liye thousands of simple cores se throughput optimize karte hain, jabki CPUs sequential tasks ke liye large caches wale few complex cores se latency optimize karte hain.

Arithmetic intensity kya hai aur GPU speedup ke liye kyun matter karti hai?

Arithmetic intensity, floating-point operations ka bytes moved se ratio hai (FLOP/byte). Yeh isliye matter karta hai kyunki CPU aur GPU ke beech data transfer expensive hai — transfer overhead overcome karne aur speedup achieve karne ke liye typically high arithmetic intensity (>10 FLOP/byte) chahiye.

Heterogeneous Amdahl's Law speedup formula derive karo :: Serial fraction $f_{s}$ , parallel fraction $f_{p}$ , GPU speedup $S_{GP U}$ , aur transfer overhead $t_{x f er}$ ke liye: Original time = 1. Naya time = $f_{s} + \frac{f _{p}}{S _{GP U}} + t_{x f er}$ . Therefore, $S_{o v er a l l} = \frac{1}{f _{s} + \frac{f _{p}}{S _{GP U}} + t _{x f er}}$ . Yeh dikhata hai ki serial code aur transfer overhead infinite GPU performance ke baad bhi speedup limit karte hain.

GPU use karne ki break-even condition kya hai?

Work

W

\frac{2 D \cdot F _{C P U} \cdot F _{GP U}}{B ( F _{GP U} - F _{C P U} )}

se zyada hona chahiye jahan

D

data size hai,

B

bandwidth hai, aur

F

FLOPS hain. Intuitively: computational advantage ko PCIe par data do baar (GPU ko aur wapas) move karne ki cost se zyada hona chahiye.

Heterogeneous computing mein teen task partitioning models kaunse hain?

1) Offload model: CPU control karta hai, GPU compute kernels karta hai. 2) Pipelined model: Alag processors par alag stages, alag data items ko overlap karte hue. 3) Collaborative model: CPU aur GPU simultaneously ek hi problem ke alag parts par kaam karte hain.

Full utilization ke liye GPUs ko thousands of threads kyun chahiye?

GPUs latency hiding use karte hain — jab kuch threads memory ka wait kar rahe hote hain, tab doosre execute karte hain. GPU cores ke paas complex out-of-order execution ya large caches nahi hote. Saare cores busy rakhne ke liye ~10× zyada threads chahiye cores se, memory latency ko doosre threads ki computation se chhupate hue.

Parallel tree reduction ka work aur span kya hai?

Work:

O (n)

total operations (sequential jaisa,

n - 1

additions se kam nahi ho sakta). Span:

O (lo g n)

critical path depth (har level data half karta hai). Speedup span aur coordination overhead se limited hai.

Data centers mein heterogeneous computing ka primary advantage kya hai?

Energy efficiency. GPU zyada power consume karta hai (jaise 400W vs 150W), lekin tasks bahut jaldi complete karta hai (jaise 20× speedup), aur zyada time idle rehta hai. Total energy 5-10× kam ho sakti hai, scale par significant cost savings hoti hain.

GPU ki jagah FPGA kab use karna chahiye?

FPGA use karo jab: 1) Latency critical ho (microseconds vs milliseconds), 2) Power bahut constrained ho (10-50W vs 200-400W), 3) Algorithm stable ho (aksar nahi badlega, resynthesis cost avoid karo), 4) Custom datapath chahiye jo GPU ke SIMT model ke liye suited nahi. Example: high-frequency trading, embedded systems.