Use Intel VTune and AMD uProf for Advanced Analysis

Topic Overview

When perf stat Is Not Enough

Intel VTune and AMD uProf add source-line mapping, memory access analysis, and microarchitecture-specific metrics like frontend stalls and port utilization. Kernel teams use them when perf events are multiplexed too aggressively or when you need cache-line conflict detail that generic counters miss.

Workflow Overview

Build with debug symbols (-g). Run the profiler in hotspot or memory-access mode. Drill from function to source line to assembly. Compare before/after optimization runs saved as separate sessions.

bashCopy
Loading…

• Install the microarchitecture-specific event pack for your CPU generation
• Profile realistic input sizes; tiny inputs mislead cache analysis
• Pair with flame graphs: VTune for line-level, perf for regression CI
• Document compiler flags in the report so results are reproducible

Working Through the Exercise

Keep the relevant documentation open while you implement. When your output disagrees with the reference, trace one failing case by hand before changing random lines.

• Trace first: walk one failing input step by step
• Read the manual: skim the official doc for the mechanism named in this task
• Compare baselines: save measurements from the prior step so speedups are honest

Why for this exercise

You will document a profiling plan using VTune or uProf on a sample binary and interpret a provided summary table. This exercise requires mapping one hotspot function to a concrete optimization hypothesis.

Your Task

VTune's Hotspots and Microarchitecture views, and AMD uProf's, are built from event-based sampling. Every N occurrences of an event (the sample-after value, SAV), the PMU records the current instruction pointer. Samples × SAV estimates the event count per function and source line. Ratios of those estimates (CPI, LLC misses per kilo-instruction) show why a hotspot is slow. Build the report from recorded samples.

Input

cCopy
Loading…

The default SAVs are cycles 2000003, instructions 2000003, and llc_miss 20011 (VTune uses odd periods, which avoids aliasing with loops).

Rules

• Estimates. estimated events = samples × SAV of that event. The header prints the estimated total cycles and the total cycle samples.
• hotspots: functions sorted by cycle samples (ties by name). Each shows:
  • its share of the cycle samples (1 decimal);
  • CPI = estimated cycles / estimated instructions (2 decimals);
  • LLC MPKI = estimated misses × 1000 / estimated instructions (1 decimal).
  • All are rounded half up, and a zero denominator gives n/a.
• Hint, using truncated CPI × 100 and MPKI × 10:
  • no instruction samples → (no instruction samples);
  • CPI > 1.00 and MPKI >= 5.0 → -> memory bound: improve data locality;
  • CPI > 1.00 → -> stalled, but not on LLC misses: check dependencies and branches;
  • CPI <= 0.50 → -> retiring well: reduce the instruction count (vectorise);
  • otherwise nothing.
• lines FUNC: each line's cycle samples and its share of the function, sorted by samples (ties by line number). A function without cycle samples prints lines FUNC: no cycle samples.
• Errors: sav: unknown event or bad period and sample: bad event, line or count.

Output

cCopy
Loading…

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Scale every event by its own SAV before forming ratios. Events sampled at different rates cannot be compared as raw sample counts.
2. Rank by cycles (where the time went), but explain with ratios (why).

Hidden tests cover custom SAVs that change the CPI, a function with no instruction samples, ties in the ranking, hotspots 1, per-line tables with ties, and invalid samples.