Performance Counters and Telemetry — Step-by-Step Walkthrough

Step-by-step analysis walkthrough

Follow this walkthrough when you own Performance Counters and Telemetry in a performance review or architecture signoff meeting.

1. Confirm workload and analysis tag.

2. Open Counter integrity and stall attribution dashboard and capture worst cluster.

3. Classify bottleneck type.

4. Map cluster to structure.

5. List competing hypotheses.

6. Run cheapest falsifying experiment.

7. Estimate metric delta.

8. Choose bounded change.

9. List regression surfaces.

10. Replay workloads.

11. Write decision memo.

12. Capture methodology guardrail.

Artifacts to collect

• Workload list

• PMU/trace config

• Metric dashboard

• Decision memo

Decision memo template

DECISION MEMO — Performance Counters and Telemetry
metric:
hypothesis:
experiment:
decision:
validation:

Architecture deep dive

PMU evidence beats intuition for architecture decisions.

Concept diagram

TOP-DOWN PERFORMANCE METHOD

Total cycles
 ├─ Retiring useful work
 ├─ Frontend bound
 ├─ Bad speculation
 ├─ Backend core bound
 └─ Backend memory bound

Only after classification should you propose cache, branch, pipeline, or NoC changes.

Metric graph

ROOFLINE SKETCH

Performance
  ^
  |                     compute roof
  |-------------------------------
  |                   /
  |                 /
  |               /   ● workload A (compute-bound)
  |             /
  |   ● workload B (memory-bound)
  +---------------------------------> arithmetic intensity
        memory bandwidth slope

Metrics and artifacts

• PMU event sets

• roofline chart

• top-down stall breakdown

• workload sensitivity matrix

Mini case study

Team proposed wider SIMD but roofline showed memory-bound kernel — bandwidth upgrade and locality fix delivered 2× speedup at lower area cost.

Debug branches

• If counters disagree with sim, align workload and warmup.

• If bottleneck unclear, use top-down method before microarch tweaks.

Senior review question

Ask: what single metric would prove this concept is working or failing on your workload?

Key takeaways

• Connect every architecture claim to a workload and measurable metric.

• State verification and PPA impact before proposing design changes.

Common pitfalls

• Feature-driven design without MPKI/IPC/bandwidth evidence.

• Ignoring coherency and NoC traffic in cache and accelerator sizing.

Study notes

Re-read this topic with one concrete workload.