Profiling — gprof, perf, Valgrind - Callgrind

5.3.16 · Coding › Build Systems & Toolchain

Profile kyon karein?

DO strategies kyon? Ek tradeoff hai: $accuracy of counts ↑ ⟹ overhead ↑ ⟹ measured timing distorts true timing$

Teen tools ek nazar mein

Tool	Mechanism	Kya measure karta hai	Overhead	Recompile chahiye?
gprof	instrumentation + sampling	self/total time, call graph	medium	haan (`-pg`)
perf	hardware counters + sampling	cycles, cache misses, branches	~1–5%	nahi (`-g` helpful hai)
Callgrind (Valgrind)	full CPU simulation	exact instr counts, cache sim	20–100×	nahi

gprof — KYA & KAISE

KAISE kaam karta hai (model derive karo):

-pg compiler se mcount() ka call har function ki entry par insert karaata hai. Yeh caller→callee edge record karta hai, call graph aur call counts banata hai (instrumentation → exact counts).
Ek periodic timer (SIGPROF, ~100 Hz) PC sample karta hai taaki self time per function estimate ho sake (sampling → statistical time).

Self time vs total (cumulative) time — key distinction:

Self time = function ke apne body ke andar spend kiya gaya time.
Total time = self time + uske dwara call ki gayi sab cheezein ka time.

$ gcc -pg -O2 prog.c -o prog
$ ./prog            # gmon.out likhta hai
$ gprof ./prog gmon.out > report.txt

Flat profile columns: % time | self seconds | calls | self ms/call | name.

KAISE (sampling logic derive karo): PMU ko ek event count karne ke liye program kiya ja sakta hai (jaise CPU cycles). Har $P$ events ke baad yeh ek interrupt raise karta hai; perf us waqt PC record karta hai. Yeh event-based sampling hai — jahan program zyaada kaam karta hai wahan samples dense hote hain.

$ perf stat ./prog              # summary counters (cycles, IPC, cache-misses)
$ perf record -g ./prog         # -g = call graph capture karo
$ perf report                   # interactive TUI
$ perf annotate                 # per-instruction hotness

Valgrind / Callgrind — KYA & KAISE

$ valgrind --tool=callgrind ./prog     # callgrind.out.<pid> likhta hai
$ callgrind_annotate callgrind.out.<pid>
$ kcachegrind callgrind.out.<pid>      # GUI call graph

20–100× slowdown ke bawajood use kyon karein?

Deterministic: same input → identical counts. Koi timer noise nahi, CI regression tests ke liye perfect.
Instructions/calls exactly count karta hai, isliye cost ek single line tak attribute ki ja sakti hai.
--cache-sim=yes L1/LL caches model karta hai; --branch-sim=yes branch prediction model karta hai — bina PMU access ke.

Figure — Profiling — gprof, perf, Valgrind - Callgrind

Worked examples

Worked example 1 — gprof flat profile padhna

%time  self(s)  calls   name
 72.0    3.60    1e6     compute_dist
 18.0    0.90    1e6     normalize
 10.0    0.50    1       main

Q: kahan optimize karoge? Step 1: compute_dist self time ka 72% hai. Yeh step kyon? 80/20 ke hisaab se, isse optimize karne par sabse bada return milega; isse half karne se total runtime ~36% bachegi. Step 2: Isse $1 0^{6}$ baar call kiya gaya hai. Yeh step kyon? Per-call cost = $3.60/1 0^{6} = 3.6 μ s$ ; dekho ki calls reduce ki ja sakti hain (memoize, vectorize), sirf faster nahi banani.

Worked example 3 — perf stat diagnosis

8.0e9 instructions   #  0.45 insn per cycle
1.8e10 cycles
2.0e8 cache-misses   #  12% of all cache refs

Step 1: IPC = $8 \times 1 0^{9} /1.8 \times 1 0^{10} = 0.44$ → stalling. KYo: ~3–4 se kaafi neeche, CPU bahut wait karta hai. Step 2: 12% miss rate bahut badi hai. Yeh step kyon: stalls memory se explain ho rahe hain. Fix path: data locality improve karo (struct-of-arrays, blocking) — algorithmic changes nahi.

Recall Feynman: ek 12-saal ke bacche ko explain karo

Socho tum homework karte waqt apna time time karo. Kaunsa subject sabse slow hai yeh guess karne ke bajaye, har minute likhte ho ki abhi kya kar rahe ho. Ek ghante baad count karo: "math = 40 tally marks, reading = 5." Ab tum jaante ho ki math tumhara time kha raha hai, toh wahan tumhe faster hona chahiye. Profilers programs ke liye yahi karte hain — woh program ko baar baar tap karte hain aur poochte hain "abhi tum kya kar rahe ho?" aur jawab tally karte hain. Lazy tarika (perf) bas kabhi kabhi jhaankta hai; careful slow tarika (Callgrind) har ek second dekhta hai lekin bahut zyaada time leta hai.

Flashcards

Optimization ka cardinal rule kya hai?

Optimize karne se pehle measure (profile) karo — bottlenecks ke baare mein intuition usually galat hota hai.

Instrumentation vs sampling profiling?

Instrumentation counters insert karta hai (exact counts, high overhead, timing distort hoti hai); sampling periodically interrupt karke PC record karta hai (low overhead, statistical estimate).

gprof ke liye kaunsa flag compile karta hai aur running se kaunsi file banti hai?

-pg; running se gmon.out banti hai.

gprof self time vs total/cumulative time?

Self = function ke apne body mein time; total = self + uski sab calls mein time.

Samples se function ka self time estimate karne ka formula?

T_{se l f} \approx n_{f} Δ t = (n_{f} / N) T_{t o t a l}

— samples ka fraction × total runtime.

perf events measure karne ke liye kya use karta hai?

Kernel perf_events subsystem jo CPU ke hardware PMU (performance counters) ko drive karta hai, event-based sampling ke zariye.

IPC define karo aur low IPC kya imply karta hai.

IPC = instructions retired / CPU cycles; low IPC (jaise <1) matlab CPU stall kar raha hai, often cache misses ya branch mispredictions ki wajah se.

1% L1 cache miss potentially dominant kyon hota hai?

DRAM tak ek miss ~100+ cycles cost karti hai vs L1 hit ke liye ~4, isliye thodi si misses bhi bahut time add karti hain.

Callgrind ka main downside aur main upside?

Downside: 20–100× slowdown aur yeh simulate karta hai (real wall-clock nahi). Upside: deterministic, bit-exact instruction/call counts, CI ke liye reproducible.

Fraction p ko s× speed up karne par Amdahl's law ka speedup formula?

Speedup = 1/ ((1 - p) + p / s)

; ceiling

1/ (1 - p)

hai.

Optimized (-O2) build profile karna kyon zaroori hai, -O0 nahi?

Optimizer inline/vectorize karta hai; -O0 profile aisi code ki taraf point karta hai jo release binary mein exist hi nahi karti.

Quick counter summary vs call-graph record ke liye perf command?

Summary ke liye perf stat ./prog; call graph ke liye perf record -g ./prog phir perf report.

Connections

Build Systems & Toolchain
Compiler Optimization Flags (-O2, -O3, inlining)
Cache Hierarchy & Locality of Reference
Amdahl's Law & Scalability
Branch Prediction & Pipelining
Debugging with gdb
Benchmarking & Microbenchmark Pitfalls