Intel VTune and AMD uProf
VTune Profiler (a free download, standalone or inside the oneAPI toolkits) and AMD uProf (5.3, 2026-06-17) are the vendor profilers that turn PMU samples into named bottleneck categories. Use them after linux-perf has named a hot function and the question has become why that function is slow: front end, bad speculation, memory, or core execution.
Contract
| Field |
Bound contract |
| Trigger |
A hot function is known and the user asks which pipeline stage or memory level limits it, wants DRAM bandwidth utilization, wants a roofline chart, or asks how to run VTune or uProf. |
| Authority |
Reversible local: writes only result directories (-result-dir or --output-dir targets) and report files in the working directory; rollback is deleting them. Driver installation for hardware sampling is proposed to the user, never performed. No remote mutation. |
| Side effect |
Result directories on disk. Hardware event collection loads the vendor sampling driver or uses perf_event_open under the same paranoid rules as perf. |
| Done |
The report names the dominant top-down category for the hot function with its percentage, the memory level or bandwidth figure behind it when memory-bound, and the measured versus peak bandwidth or the roofline position when asked. |
Inputs
- Binary built with
-g and the release optimization level; add -fno-omit-frame-pointer for reliable stacks.
- CPU vendor: VTune on Intel, uProf on AMD. VTune's hardware analyses need Intel PMU features; on AMD hosts it falls back to software sampling.
- Environment:
source /opt/intel/oneapi/vtune/latest/env/vars.sh puts vtune and vtune-gui on the path (default oneAPI layout). uProf installs AMDuProfCLI, AMDuProfPcm, and the AMDuProf GUI; AMDuProfCLI --version confirms it.
- The question: where (hotspots), why (top-down), or how far from the hardware ceiling (memory access, roofline).
Procedure
- Hotspots first. VTune:
vtune -collect hotspots -result-dir r_hot ./prog, then vtune -report hotspots -r r_hot -format csv -report-output hotspots.csv (-csv-delimiter comma fixes the delimiter across locales). uProf: AMDuProfCLI collect --config tbp --output-dir uprof_out ./prog, then AMDuProfCLI report --input-dir uprof_out/<session-dir> writes a CSV summary. Done when: the top functions by CPU time are listed.
- Explain the hot function with top-down analysis. VTune:
vtune -collect uarch-exploration -result-dir r_uarch ./prog and vtune -report summary -r r_uarch. The CLI token is uarch-exploration; general-exploration is the deprecated alias and microarchitecture-exploration is the GUI label only. Read the four top-level categories, which sum to the pipeline slots: Retiring (useful work), Bad Speculation (mispredicted paths), Front-End Bound (fetch and decode starvation), Back-End Bound (execution or memory waits), the last split into Memory Bound (L1, L2, L3, DRAM Bound) and Core Bound. VTune highlights a category when it exceeds its own built-in expectation for the workload class; read the highlight, not a fixed number, because the healthy split for a vectorized kernel differs from a branchy parser. uProf: AMDuProfCLI collect --config hotspots adds call stacks to time-based sampling; list this version's configurations with AMDuProfCLI info --list collect-configs before choosing one. Done when: the dominant category and its share are named for the hot function.
- When Back-End Bound dominates, measure memory. VTune:
vtune -collect memory-access -result-dir r_mem ./prog; the summary reports Memory Bound share, LLC miss rate, DRAM bandwidth achieved, and NUMA remote accesses on multi-socket hosts. Compare achieved DRAM bandwidth with the platform peak VTune reports for the socket; a workload at a small fraction of peak with high Memory Bound is latency-bound (pointer chasing, poor locality), one near peak is bandwidth-bound. uProf: --config memory samples with IBS to find false cache-line sharing. Fix paths: layout changes and locality (cpu-cache-opt), NUMA placement (numa-programming). Done when: the memory level or the bandwidth ratio that limits the function is stated.
- When Retiring dominates but time is still high, the code is compute-bound: vectorization (
simd-intrinsics) or algorithmic work is the lever. Done when: the recommendation names the lever.
- Roofline, when asked.
vtune -collect hpc-performance -result-dir r_hpc ./prog collects the FLOP and bandwidth data; the roofline chart renders in vtune-gui (or VTune Profiler Server), not as a CLI report. Read the position: a kernel under the sloped bandwidth roof is memory-bound, one under the flat compute roof is compute-bound. For a manual roofline, arithmetic intensity is FLOPs divided by bytes moved; peak FLOP rate comes from cores times frequency times FLOPs per cycle per core, and peak bandwidth from the platform specification. likwid-perfctr -C 0 -g FLOPS_DP ./prog and -g MEM measure the two axes on Linux; group names are per microarchitecture and likwid-perfctr -a lists the ones for this CPU. Done when: the kernel's roofline position and the limiting roof are stated.
- Threading, when the program is parallel and scaling is poor:
vtune -collect threading -result-dir r_thr ./prog reports lock contention and parallel efficiency; uProf's --config threading covers the same question. Done when: the top synchronization object or the idle fraction is named.
Failure and recovery
| Failure |
Cause |
Fix |
| Hardware collection fails or falls back to user-mode sampling |
Sampling driver not loaded, or perf_event_paranoid too high |
Propose loading the vendor driver, or the same sysctl change as linux-perf; hotspots still work in software mode |
| No symbols in the report |
Build lacks -g |
Rebuild with -g; point the profiler at the symbol directory if debug info is split |
uarch-exploration unavailable on this CPU |
Non-Intel host or virtualized PMU |
Use uProf on AMD; in a VM only software hotspots are available |
uProf rejects --config name |
Configuration names vary by version |
Run AMDuProfCLI info --list collect-configs and pick from that list |
| Roofline chart missing |
Looking for it in a CLI report |
Open the hpc-performance result in vtune-gui |
| Categories do not add up |
Mixed SMT siblings or frequency scaling during the run |
Pin the workload and disable turbo for the measurement, then rerun |
Output
A microarchitecture report naming the hot functions, the dominant top-down category and share per hot function, the memory level or achieved-versus-peak bandwidth when memory-bound, the roofline position when asked, the result directory paths, and one recommended lever per hot function.
1---2name: intel-vtune-amd-uprof3description: Use when profiling with Intel VTune or AMD uProf for hotspots, top-down pipeline stalls, memory-bound analysis, or roofline data. Not for raw perf stat counters: use hardware-counters.4---56# Intel VTune and AMD uProf78VTune Profiler (a free download, standalone or inside the oneAPI toolkits) and AMD uProf (5.3, 2026-06-17) are the vendor profilers that turn PMU samples into named bottleneck categories. Use them after `linux-perf` has named a hot function and the question has become why that function is slow: front end, bad speculation, memory, or core execution.910## Contract1112| Field | Bound contract |13|---|---|14| Trigger | A hot function is known and the user asks which pipeline stage or memory level limits it, wants DRAM bandwidth utilization, wants a roofline chart, or asks how to run VTune or uProf. |15| Authority | Reversible local: writes only result directories (`-result-dir` or `--output-dir` targets) and report files in the working directory; rollback is deleting them. Driver installation for hardware sampling is proposed to the user, never performed. No remote mutation. |16| Side effect | Result directories on disk. Hardware event collection loads the vendor sampling driver or uses `perf_event_open` under the same paranoid rules as perf. |17| Done | The report names the dominant top-down category for the hot function with its percentage, the memory level or bandwidth figure behind it when memory-bound, and the measured versus peak bandwidth or the roofline position when asked. |1819## Inputs2021- Binary built with `-g` and the release optimization level; add `-fno-omit-frame-pointer` for reliable stacks.22- CPU vendor: VTune on Intel, uProf on AMD. VTune's hardware analyses need Intel PMU features; on AMD hosts it falls back to software sampling.23- Environment: `source /opt/intel/oneapi/vtune/latest/env/vars.sh` puts `vtune` and `vtune-gui` on the path (default oneAPI layout). uProf installs `AMDuProfCLI`, `AMDuProfPcm`, and the `AMDuProf` GUI; `AMDuProfCLI --version` confirms it.24- The question: where (hotspots), why (top-down), or how far from the hardware ceiling (memory access, roofline).2526## Procedure27281. Hotspots first. VTune: `vtune -collect hotspots -result-dir r_hot ./prog`, then `vtune -report hotspots -r r_hot -format csv -report-output hotspots.csv` (`-csv-delimiter comma` fixes the delimiter across locales). uProf: `AMDuProfCLI collect --config tbp --output-dir uprof_out ./prog`, then `AMDuProfCLI report --input-dir uprof_out/<session-dir>` writes a CSV summary. Done when: the top functions by CPU time are listed.292. Explain the hot function with top-down analysis. VTune: `vtune -collect uarch-exploration -result-dir r_uarch ./prog` and `vtune -report summary -r r_uarch`. The CLI token is `uarch-exploration`; `general-exploration` is the deprecated alias and `microarchitecture-exploration` is the GUI label only. Read the four top-level categories, which sum to the pipeline slots: Retiring (useful work), Bad Speculation (mispredicted paths), Front-End Bound (fetch and decode starvation), Back-End Bound (execution or memory waits), the last split into Memory Bound (L1, L2, L3, DRAM Bound) and Core Bound. VTune highlights a category when it exceeds its own built-in expectation for the workload class; read the highlight, not a fixed number, because the healthy split for a vectorized kernel differs from a branchy parser. uProf: `AMDuProfCLI collect --config hotspots` adds call stacks to time-based sampling; list this version's configurations with `AMDuProfCLI info --list collect-configs` before choosing one. Done when: the dominant category and its share are named for the hot function.303. When Back-End Bound dominates, measure memory. VTune: `vtune -collect memory-access -result-dir r_mem ./prog`; the summary reports Memory Bound share, LLC miss rate, DRAM bandwidth achieved, and NUMA remote accesses on multi-socket hosts. Compare achieved DRAM bandwidth with the platform peak VTune reports for the socket; a workload at a small fraction of peak with high Memory Bound is latency-bound (pointer chasing, poor locality), one near peak is bandwidth-bound. uProf: `--config memory` samples with IBS to find false cache-line sharing. Fix paths: layout changes and locality (`cpu-cache-opt`), NUMA placement (`numa-programming`). Done when: the memory level or the bandwidth ratio that limits the function is stated.314. When Retiring dominates but time is still high, the code is compute-bound: vectorization (`simd-intrinsics`) or algorithmic work is the lever. Done when: the recommendation names the lever.325. Roofline, when asked. `vtune -collect hpc-performance -result-dir r_hpc ./prog` collects the FLOP and bandwidth data; the roofline chart renders in `vtune-gui` (or VTune Profiler Server), not as a CLI report. Read the position: a kernel under the sloped bandwidth roof is memory-bound, one under the flat compute roof is compute-bound. For a manual roofline, arithmetic intensity is FLOPs divided by bytes moved; peak FLOP rate comes from cores times frequency times FLOPs per cycle per core, and peak bandwidth from the platform specification. `likwid-perfctr -C 0 -g FLOPS_DP ./prog` and `-g MEM` measure the two axes on Linux; group names are per microarchitecture and `likwid-perfctr -a` lists the ones for this CPU. Done when: the kernel's roofline position and the limiting roof are stated.336. Threading, when the program is parallel and scaling is poor: `vtune -collect threading -result-dir r_thr ./prog` reports lock contention and parallel efficiency; uProf's `--config threading` covers the same question. Done when: the top synchronization object or the idle fraction is named.3435## Failure and recovery3637| Failure | Cause | Fix |38|---|---|---|39| Hardware collection fails or falls back to user-mode sampling | Sampling driver not loaded, or `perf_event_paranoid` too high | Propose loading the vendor driver, or the same `sysctl` change as `linux-perf`; hotspots still work in software mode |40| No symbols in the report | Build lacks `-g` | Rebuild with `-g`; point the profiler at the symbol directory if debug info is split |41| `uarch-exploration` unavailable on this CPU | Non-Intel host or virtualized PMU | Use uProf on AMD; in a VM only software hotspots are available |42| uProf rejects `--config` name | Configuration names vary by version | Run `AMDuProfCLI info --list collect-configs` and pick from that list |43| Roofline chart missing | Looking for it in a CLI report | Open the `hpc-performance` result in `vtune-gui` |44| Categories do not add up | Mixed SMT siblings or frequency scaling during the run | Pin the workload and disable turbo for the measurement, then rerun |4546## Output4748A microarchitecture report naming the hot functions, the dominant top-down category and share per hot function, the memory level or achieved-versus-peak bandwidth when memory-bound, the roofline position when asked, the result directory paths, and one recommended lever per hot function.