5.3.16 · D5 · HinglishBuild Systems & Toolchain
Question bank — Profiling — gprof, perf, Valgrind - Callgrind
5.3.16 · D5· Coding › Build Systems & Toolchain › Profiling — gprof, perf, Valgrind - Callgrind
Shuru karne se pehle, ek chhoti vocabulary jo hum neeche har jagah use karte hain — har term plain language mein define ki gayi hai aur ek picture se anchor ki gayi hai.
Neeche wala call-tree picture ise concrete banata hai: main sabka time total ke roop mein inherit karta hai lekin uska apna self time almost nahi hota.
Neeche wali timeline dono ko contrast karti hai: instrumentation har event par thoda tax deta hai (grey ticks), jabki sampling sirf har timer interrupt par PC peek karta hai (arrows).
Bar picture dikhata hai kyun: coral (hot) block ko kuch nahi karo aur mint (untouched) block akele hi naye runtime ka floor set kar deta hai.
Aakhir mein, reason ki ek "small" cache miss rate dominate kyun kar sakta hai — miss cost per hit se enormous hai:
True or false — justify karo
True or false: profile mein main ka highest time dikhna matlab main bottleneck hai.
False — woh uska total time hai, jisme har callee included hai.
main khud usually almost kuch nahi karta; optimize karo self time se, total sirf expensive subtrees locate karne ke liye use karo.True or false: lower-overhead profiler hamesha zyada trustworthy picture deta hai.
False — low overhead (perf) ka matlab timing distortion kam hai, lekin sampling statistical hai aur rare-but-costly events miss kar sakta hai; heavy tool (Callgrind) exact counts deta hai. "Trustworthy" is baat par depend karta hai ki tumne kaun sa sawaal poocha.
True or false: Callgrind report karta hai real number of wall-clock seconds jo tumhara program liya.
False — Callgrind ek simulated CPU run karta hai aur instruction/cache events report karta hai, seconds nahi. Yeh out-of-order execution, prefetch, aur true DRAM latency ignore karta hai; real time ke liye perf use karo.
True or false: agar ek function million baar call hota hai, toh function body ko faster banana hi ek lever hai.
False — tum calls ki sankhya bhi reduce kar sakte ho (memoize karo, loop se bahar hoist karo, batch/vectorize karo). High call count khud ek signal hai ki call frequency, na sirf per-call cost, target ho sakta hai.
True or false: -O0 build ko profile karna theek hai jab tak relative percentages dekho.
False — optimizer program rewrite karta hai: inlining pure functions delete kar deta hai, vectorization hot loops reshape karta hai.
-O0 percentages aisa code describe karta hai jo release binary mein exist hi nahi karta.True or false: 1% cache miss rate itni chhoti hai ki ignore kar sako.
False — DRAM tak ek miss ~100+ cycles ki cost hai jabki L1 hit ~4 cycles ka, isliye 1% accesses total time dominate kar sakti hain. Miss rate ko hamesha miss cost ke saath weigh karo, kabhi akele mat padho.
True or false: instrumentation profilers exact call counts dete hain, isliye unka reported time bhi exact hota hai.
False — call counts exact hote hain (counter har call par tick karta hai), lekin time PC (program-counter) sampling se aata hai, jo statistical hai, aur instrumentation overhead khud us timing ko distort karta hai jise woh measure karta hai.
True or false: high IPC hamesha matlab tumhara program fast hai.
False — IPC (instructions per cycle) sirf yeh batata hai ki CPU stall nahi kar raha. Tum wasteful algorithm run karte hue efficiently instructions retire kar sakte ho; high IPC + high instruction count matlab tumhe better algorithm chahiye, better memory behaviour nahi.
True or false: perf ke under same program ke do runs byte-identical numbers denge.
False — perf timer/event interrupts aur real hardware use karta hai, isliye numbers run to run thoda hilte hain. Deterministic, reproducible counts ke liye (jaise CI regression gates) Callgrind chahiye.
Error dhundho
"IPC 0.4 hai, isliye algorithm bahut slow hai — better algorithm choose karta hun."
Galat diagnosis. Low IPC ka matlab CPU stall kar raha hai (cache misses, branch mispredicts), isliye fix hai better memory/branch behaviour (locality, layout). Better algorithm tab help karta hai jab IPC already high ho lekin instruction count large ho.
"perf report mein strlen hot dikh raha hai, isliye strlen badly written hai — replace kar do."
Error callee ko blame karne mein hai.
strlen hot isliye hai kyunki tumhara code ise bahut baar call karta hai, likely ek loop mein jahan length change nahi hoti. Caller fix karo: length bahar hoist karo, libc rewrite mat karo."Main is deeply nested loop ko optimize karunga; nested loops obviously slow part hote hain."
Measure kiye bina guess karna. Woh loop sirf 10 baar run ho sakta hai jabki ek hidden
log() kahin aur dominate kare. Pehle Profile karo; hot paths ke baare mein intuition usually galat hota hai."Callgrind ne kaha function A, function B se 3× cost karta hai, isliye mere CPU par A, B se 3× seconds lega."
Simulated instruction cost ≠ real seconds. Prefetching aur out-of-order execution real silicon par A ki zyaadatar cost hide kar sakti hai. Callgrind relative counts ke liye hai; real timing perf se confirm karo.
"gprof mein main 95% total time ke saath dikh raha hai — main main rewrite karunga."
Total time ko self time samajhna galti hai.
main ka 95% uske callees se inherited hai; uski apni body almost kuch nahi karti. Total-time subtree ko neeche follow karo us function tak jiska high self time ho."perf ka overhead ~1–5% hai, isliye main iske upar trust kar sakta hun even ek function ke liye jo total 2 microseconds chalta hai."
Ek function jo kabhi sampling interrupt tak survive nahi karta use zero ya wildly noisy samples milte hain. Low overhead, low sample counts fix nahi karta; tiny/rare code ke liye, sampling statistically blind hai.
"Maine -pg add kiya profile karne ke liye, clarity ke liye -O0 rakha, aur clean report mili."
Do errors ek saath:
-pg us debug binary ko measure karta hai jise optimizer waise bhi transform kar deta, aur -O0 inlining/vectorization disable karta hai. Report non-existent release behaviour describe karti hai.Why questions
Profiling "pehle measure karo, phir optimize karo" par kyun zor deta hai instead of sirf code padho?
Kyunki real cost aise cheezein dominate karti hain jo source mein invisible hain: cache misses, branch mispredicts, syscalls, aur call frequency. Woh line jo lagti hai expensive woh rarely hoti hai.
Higher count accuracy ka matlab usually higher overhead kyun hota hai?
Har event ko exactly count karne ke liye tumhe instrument karna padta hai (har event par kaam insert karna), aur woh inserted kaam khud time consume karta hai — isliye zyada precisely measure karna us timing ko disturb karta hai jise tum measure karte ho.
perf zyada samples wahan capture kyun karta hai jahan program zyada kaam karta hai (event-based sampling)?
Yeh ek hardware event (jaise cycles) count karta hai aur har events ke baad interrupt karta hai, jahan sampling period hai — ek fixed event budget jo tum (ya perf) set karte ho. Busy code un events ko jaldi burn karta hai, zyada baar interrupts trigger karta hai, isliye hot regions mein naturally denser samples accumulate hote hain.
Callgrind ko CI regression tests ke liye kyun value kiya jaata hai despite 20–100× slower hone ke?
Kyunki yeh deterministic hai: identical input se identical counts milte hain bina kisi timer noise ke, isliye genuine +2% instruction regression run-to-run jitter se alag dikh sakta hai — jo perf ka noise hide kar deta.
Hum self time ko total time se alag kyun karte hain?
Self time batata hai kaun sa single function rewrite karna hai; total time batata hai calls ka kaun sa subtree expensive hai. Total time se optimize karne par tum
main par pahunch jaate ho, jise tum directly speed up nahi kar sakte.-fno-omit-frame-pointer add karna perf ke call graphs mein kyun help karta hai?
Optimizers frame-pointer register reuse kar sakte hain, woh chain todh ke jo perf callers reconstruct karne ke liye follow karta hai. Frame pointer preserve karna woh chain intact rakhta hai, accurate caller→callee attribution deta hai.
12% cache-miss rate kyun low IPC explain kar sakta hai, aur algorithm change galat fix kyun hoga?
Har miss pipeline ko ~100 cycles ke liye stall kar deta hai, isliye CPU instructions retire karne ke bajaye wait karne mein cycles bitata hai — yahi low IPC hai. Ilaaj data locality hai (blocking, struct-of-arrays), naya algorithm nahi.
Edge cases
Ek aisi function ka self time kaisa dikhta hai jo sirf doosri functions call karti hai aur khud kuch nahi karti?
Uska self time ~zero hota hai jabki total time large ho sakta hai. Yeh pure delegator hai; self time se profiling correctly ise skip karti hai.
Jab ek hot function ko -O2 se inline kar diya jaata hai toh gprof ki picture ka kya hota hai?
Uski body caller mein merge ho jaati hai, isliye woh profile se disappear ho sakti hai — uski cost ab jisne ise inline kiya usse attributed ho jaati hai. Exactly isliye
-O0 aur -O2 profiles alag hote hain.Ek function ke liye perf kya report karta hai jo itni short-lived hai ki do timer interrupts ke beech mein poori run ho jaati hai?
Possibly koi samples nahi, ise free dikhata hai. Sampling ka ek resolution floor hota hai; genuinely tiny/rare code ko exact tools (Callgrind) ya microbenchmarks chahiye dikhne ke liye.
Amdahl's ceiling: agar hot function runtime ka fraction hai, toh uski infinite speedup ke saath bhi best possible total speedup kya hai?
At most — un-optimized 28% sab kuch cap karta hai. Effort invest karne se pehle yeh predict karo. Dekho Amdahl's Law & Scalability.
Agar cache-references essentially zero hai — kya reported miss rate meaningful hai?
Nahi — miss rate hai misses ÷ references, isliye near-zero denominator se divide karne par percentage unstable aur meaningless ho jaata hai. Us degenerate case mein absolute miss counts report karo.
CPU ke peak ke paas IPC (jaise ~3.5 of 4) combined with huge instruction count kya batata hai?
Hardware near-optimally chal raha hai; machine problem nahi hai — tum simply bahut zyada kaam kar rahe ho. Lever hai lower-complexity algorithm, memory ya branch tuning nahi.
Yahan in traps ke liye revisit karne layak related prerequisites: Cache Hierarchy & Locality of Reference, Branch Prediction & Pipelining, Compiler Optimization Flags (-O2, -O3, inlining), Benchmarking & Microbenchmark Pitfalls, aur Debugging with gdb.
Recall Yahan har trap ka one-line summary
Sahi cheez measure karo (self vs total), sahi tool se (sampling vs exact), sahi binary par (-O2 -g), aur metrics ko saath mein padho (miss rate ko miss cost chahiye; IPC ko instruction count chahiye) — kabhi akele nahi.