1. A basic mindset of CPU performance analysis
• Optimization is driven by careful performance analysis, not intuition.
• Full stack, short board, joggle, spikes, long tail
• Telemetry/APM agent à Please fix other issues first
• How can we further accelerate our code ?
• HW utilization and saturation, and also errors.
• even if the CPU occupancy (not real utilization) reaches 99%
• Increase as many Instructions per cycle (IPC) ↑ as possible à Optimizable
• elapsed time ↓, retired instructions per functional block ↓
• real walked cycles (not crystal clock/tsc) before the next branch↓
• cache-references ↑ + cache-misses ↓
• cache (I, D, TLB) ↑ and memory latency ↓ hierarchy
• branch-instructions ↓ + branch-misses ↓
• frontend stalled cycles ↓
• utilization of execution units ↑
• backend stalled cycles ↓
• execution units and types (Int, FP, Scalar, Vector) ↑
• More CPU HW details
• Out of order Window, Scheduler Entries …
• Register Files, Allocation Queue …
• Smarter speculation/prefetch … algorithms
• Cstate change, uncore iio/imc …
• check https://perfmon-events.intel.com/
• Workload Classification :: Top-down Microarchitecture Analysis (not for CLK)
• http://www.cs.technion.ac.il/~erangi/TMA_using_Linux_perf__Ahmad_Yasin.pdf
• keep performance in mind as you make early design and architectural decisions
Performance bottlenecks
Distributed Services
Components and language
Runtime System (Lib, OS, VM, MM)
Data structures, algorithms
ISA (Architecture)
CPU Microarchitecture
Vendor Logic/Devices/Electrons
Instructions Branch Blocks
Observable
HW Platform Configurations
(dies, mem chips, firmware, power)
Scalable Application Code
Architecture
HW events
Model Specified
HW events
Next Page : Perf - Linux Kernel official performance analyzing tool
FE à I-Cache, Decode
Branch, μop cache
BE à Mem load/store
Execution, D-Cache
Is μOP
Queued
And
Retired
?
Monitoring hardware with hardware (PMU)
Monitoring interesting event with counter (PMC)
How the instructions flow reaches this event
