stall-analysis —— CPU 流水线停顿模式实验

通过 4 种典型程序模式，用 perf stat -e stalled-cycles-frontend,stalled-cycles-backend 精准区分"取指瓶颈"和"数据瓶颈"。

1. 快速开始

make            # 编译
make run        # 跑全部 4 种模式对比
make perf-all   # 逐模式 perf stat（含停顿 + 缓存 + 分支事件）

2. 为什么要区分前端 vs 后端停顿

perf stat 看 IPC 低，只能知道"CPU 在等"。区分前端/后端才能知道在等什么：

IPC 低 (例如 <0.7)
  │
  ├── stalled-cycles-frontend 高 (>30% of cycles)
  │     → 前端瓶颈：喂不饱流水线
  │       ├── I-cache miss → 代码段太大或跳转太散
  │       ├── 分支预测失败 → 频繁冲刷流水线
  │       └── 取指带宽不足 → 指令太密
  │
  └── stalled-cycles-backend 高 (>30% of cycles)
        → 后端瓶颈：流水线满了但在等数据
          ├── D-cache miss → 数据布局差或随机访问
          ├── 长依赖链 → 算法串行限制了 ILP
          └── 执行单元忙 → 密集的 FPU/除法操作

3. 程序结构

模式	命令	停顿类型	根因	预期 IPC
1 纯计算	./stall_analysis 1	都低	无瓶颈（对照组）	>2.5
2 间接调用	./stall_analysis 2	前端	函数指针 → 间接分支预测失败 + I-cache miss	<1.0
3 随机访存	./stall_analysis 3	后端	随机 D-cache miss → ALU 空等	<0.5
4 依赖链	./stall_analysis 4	后端	a=a*13+7 串行依赖，ILP=1	~0.25

每个模式最少跑 3 秒，确保 perf stat 有足够的采样时间。

4. 代码设计

4.1 总体结构

main 只是分发器：读 argv[1] 选模式（0 = 全部），把真正的工作交给 4 个 run_* 函数；所有模式都用一个统一的 bench_seconds() 模板驱动——它固定跑满 SECONDS 秒并统计吞吐，保证 perf stat 有稳定的采样窗口；最后 print_perf_hints() 打印该模式对应的 perf 命令与预期。

四个 run_* 与停顿类型的对应关系：

函数	制造哪种停顿	核心手法
run_compute	无（对照）	4 条独立累加链
run_indirect_calls	前端	函数指针数组 + 目标每轮变
run_random_mem	后端·cache	idx=arr[idx] 依赖链 + 随机索引
run_dependency_chain	后端·依赖	a=a*13+7 串行依赖，ILP=1

4.2 计时框架 bench_seconds

template<typename Func>
double bench_seconds(const char* name, Func fn) {
    volatile long sink = 0;
    long total = 0;
    auto t0 = now();
    while (true) {
        fn(sink);
        total += ITERS;
        if (elapsed() >= SECONDS) break;   // 固定跑满 SECONDS 秒
    }
    return total / secs / 1e9;             // 吞吐: 亿次/秒
}

三个要点：

1. 固定时间窗：用 wall-clock（std::chrono）保证每种模式至少跑 SECONDS 秒，perf 才有足够采样量，避免"循环太快 → 事件数太少 → 百分比噪声大"。
2. volatile long& sink：把每轮结果写进 sink，且 sink 是 volatile，强制编译器保留循环体，防止 -O2 把"无副作用的循环"整体消除（否则 perf 什么停顿都测不到）。
3. 模板驱动：run_* 签名统一为 void(volatile long&)，放进 bench_seconds 模板即被统一调度，新增模式只写一个函数 + 一处分发。

4.3 四个模式的核心实现

4.3.1 模式1 纯计算（对照组）

void run_compute(volatile long& sink) {
    volatile long a = 1, b = 2, c = 3, d = 4;
    for (int i = 0; i < ITERS; i++) {
        a = a + b;   // 4 条链互无依赖
        b = b + c;
        c = c + d;
        d = d + a;
    }
    sink = a + b + c + d;
}

4 条独立的累加链，彼此不依赖 → CPU 可乱序并行（ILP 高）、无内存访问、无分支 → 前端/后端停顿都低，IPC 高（>2.5）。它是"理想态基线"，用来对比其它模式差在哪。

4.3.2 模式2 函数指针间接调用（前端停顿）

VoidFn fns[] = {add1, sub1, mul2, div2, xor1, shl1, shr1, inc3,
                add1, sub1, mul2, div2, xor1, shl1, shr1, inc3};  // NFNS = 16
void run_indirect_calls(volatile long& sink) {
    volatile long v = 42;
    for (int i = 0; i < ITERS; i++)
        fns[i % NFNS](v);   // 间接调用，目标每轮都变
}

fns 是 16 个函数指针，i % NFNS 让调用目标在 16 个函数间循环切换：

• 间接分支：目标地址来自内存（函数指针表），分支预测器学不到规律 → 间接分支预测失败，流水线被冲刷；
• I-cache miss：16 个函数体分散在代码段，轮流执行让指令缓存命中率下降。

两者都发生在"取指/译码"阶段 → 表现为 前端停顿高。

4.3.3 模式3 随机内存访问（后端停顿 · cache miss）

void run_random_mem(volatile long& sink) {
    static std::vector<int> arr(N);          // 16M 元素, 远超 cache
    volatile long sum = 0;
    size_t idx = 0;
    for (int i = 0; i < ITERS; i++) {
        idx = arr[idx % N] % N;              // 依赖链: 下个索引来自本次结果
        sum += arr[idx];
    }
    sink = sum;
}

• 依赖链：idx 的下一跳依赖上一次读出的 arr[idx]，CPU 必须等这次访存返回才能算下一跳 → 硬件预取器完全失效；
• 随机索引：arr 有 16M 元素（远超 L1/L2/L3），随机访问让各级缓存全 miss，数据只能从 DRAM 取（~100ns/次）；
• ALU 算 sum += arr[idx] 只需 1 cycle，但要在等内存返回的几十 cycle 里空转 → 表现为 后端停顿（cache miss）高，且 cache-misses 极高。

4.3.4 模式4 长数据依赖链（后端停顿 · 依赖）

void run_dependency_chain(volatile long& sink) {
    volatile long a = 1;
    for (int i = 0; i < ITERS; i++)
        a = a * 13 + 7;     // 每轮都依赖上一轮的 a
}

a 的每次更新都依赖上一轮的 a → ILP = 1，CPU 无法并行。瓶颈是 ALU 的乘法延迟（~4 cycles），每轮至少等 4 cycle 才能继续。这是纯计算依赖、无内存访问 → 后端停顿高，但 cache-misses 低（区别于模式3）。

4.4 关键设计决策

决策	取值	原因
N	16M	数组远超 cache，确保随机访存是真 miss 而非命中
ITERS = N/4	~4M/轮	单轮循环体很轻，需海量迭代才能跑满 SECONDS 秒
SECONDS	3	perf 采样窗口下限，事件数太少百分比会失真
volatile	sink/变量	防止 -O2 把无副作用循环整体消除
编译 -O2	非 -O0/-O3	-O0 引入无关指令噪声；-O3 可能向量化/展开，掩盖停顿现象
函数指针数组	16 项循环	让分支目标不可预测，稳定触发间接分支失败

4.5 编译与优化陷阱

• 为什么不用 -O0：-O0 下每个 C++ 语句都直译成多条指令，循环里充斥栈读写噪声，stalled-cycles 比例会被稀释，看不清真正的停顿模式。volatile 在 -O0 也有效，但噪声更大。
• 为什么不用 -O3：-O3 会自动向量化、循环展开、甚至把模式3的指针追踪链重排成可预取形式——这恰恰消除了我们想观测的停顿，教学目的落空。
• volatile 的作用域：只加在"会被写回、且结果要参与 sink"的变量上；模式内部的临时变量（如 i、idx）不需要 volatile，否则会拖慢循环、改变停顿比例。

一句话：四个模式都用最轻的循环体 + volatile 防消除，靠"分支目标不可预测 / 内存依赖链 / 算术依赖链"三种最小的代码特征，分别精准触发前端停顿与两类后端停顿——代码越简单，perf 的归因越干净。

4.6 编译器优化等级 O0 / O1 / O2 / O3 差异

优化等级决定编译器"重写"代码的激进程度：它改变指令条数、依赖链形态、是否向量化、是否消除循环。对 stall 实验，优化等级直接决定 instructions / IPC 和你想观测的停顿是否还存在——所以专门讲清楚。

表 4.6 四级优化对照（以 GCC/Clang 为准）

维度	-O0	-O1	-O2（本实验选用）	-O3
定位	调试优先，几乎不优化	基础优化	速度与体积平衡（默认发布级）	极致速度
逐语句直译	是（每条 C++ 直译多条指令）	否	否	否
死代码/无副作用循环消除	否	是	是	是
指令调度（重排减依赖停顿）	否	弱	是	是
寄存器分配优化	弱	是	是	是
循环展开	否	否	部分	激进
自动向量化（SIMD）	否	否	否	是
函数内联	否	简单内联	跨模块内联	更激进
强度削减（如 a*13+7→移位）	否	部分	是	是
调试信息 -g 配合	最佳（变量可看）	较好	可用	较差（代码变形大）

4.6.1 各级对本实验四模式的具体影响

• -O0：run_* 里每个 C++ 语句都直译成多条 mov/栈读写，循环充斥无关指令噪声。好处是 volatile 一定有效、循环绝不被消除；坏处是 stalled-cycles 比例被稀释——你看到的停顿是"噪声 + 真停顿"的混合物，看不清真正的瓶颈模式。模式1 在 -O0 下 IPC 可能比 -O2 还低，但那不是架构瓶颈，是编译器噪声。
• -O1：做常量折叠、简单内联、死代码删除，仍保留较好的调试体验。会消除明显无副作用的循环（本实验靠 volatile 顶住），但不做指令调度和向量化——停顿形态接近 -O2，只是没那么激进。适合做"-O2 行为对照"。
• -O2（本实验选用）：在 -O1 基础上加指令调度（重排指令减少伪依赖停顿）、更好的寄存器分配、部分循环展开；但不自动向量化。结果是：四个模式的"最小代码特征"都被保留——模式2 的间接调用、模式3 的依赖访存链、模式4 的串行乘法都仍在，perf 能干净地看到预期停顿。
• -O3：在 -O2 上再加自动向量化 + 激进循环展开 + 跨迭代并行。这正是本实验的"天敌"：
  • 模式3 的 idx = arr[idx] 依赖链会被尝试重排成可批处理/可预取形式，消除了我们想观测的 cache 停顿；
  • 模式4 的 a = a * 13 + 7 可能被向量化或更大展开，依赖链被打散，IPC 飙升，依赖停顿被掩盖；
  • 模式1 的 4 条链被 SIMD 化后 IPC 更高，但"对照基线"的意义仍在。

4.6.2 为什么本实验锁死 -O2

需求	-O0	-O1	-O2	-O3
循环不被消除（需 volatile 配合）	✅	✅	✅	✅
保留"最小代码特征"以观测停顿	⚠️ 噪声大	✅	✅	❌ 被优化掉
指令数接近"手写意图"（易归因）	❌ 噪声	✅	✅	❌ 变形大
可配合 -g 出火焰图	✅	✅	✅	⚠️

结论：-O0 噪声太大、-O3 把现象优化没了，只有 -O2 既保留可观测的停顿、又有干净的指令映射，是 stall 实验的甜点区。若想看"-O3 消除了什么"，可另跑 make release（见 Makefile 注）做对照。

一句话：-O0 是"调试但加噪声"，-O1 是"干净但不激进"，-O2 是"保留停顿且指令干净"的甜点区，-O3 是"把你想看的停顿优化掉"——选错等级，perf 看到的就不是 CPU 架构瓶颈，而是编译器变形的副产品。

5. perf 分析

5.1 perf 事件语义与度量

本实验关心的 perf 事件按"度量维度"分四组。下面逐个说明其语义（计数含义）、高值代表什么、以及在本实验中如何区分停顿类型。所有事件用 perf stat -e <逗号分隔> 采集；未用 -x 指定分隔符，输出为默认易读格式。

5.1.1 基础吞吐：cycles / instructions / IPC

事件	语义	单位	高值含义
cycles	CPU 核心时钟周期总数（含停顿周期）	周期	执行耗时越长越高
instructions	已**退休（retired）**的指令总数	条	完成的真实工作量
IPC	instructions ÷ cycles 的派生比值（非独立事件）	指令/周期	越高说明流水线越"喂得饱"

• cycles 是硬件时间基准；instructions 是"有用产出"。两者比值 IPC = instructions / cycles 直接衡量流水线效率。
• IPC 低 ≡ CPU 在空转等东西——这是本实验区分是否有瓶颈的第一道筛子。
• 注意：当 stalled-cycles-* 不可用（见 5.1.2）时，IPC 是判断"等什么"的唯一整体指标；但 IPC 本身不区分前端 / 后端。

5.1.2 前端/后端停顿（黄金判据，本环境不可用）

事件	语义
stalled-cycles-frontend	流水线因"取指/译码阶段"停滞的周期数——指令没喂进来
stalled-cycles-backend	流水线因"执行单元等数据/资源"停滞的周期数——指令进了但要等内存/ALU

• 这是 PMU 直接区分"前端 vs 后端"的黄金事件：stalled-cycles-frontend / cycles 即前端停顿占比，stalled-cycles-backend / cycles 即后端停顿占比。
• 本沙箱 4 个模式实测均 <not supported>：虚拟 CPU 不暴露该事件（见第 7 章 7.1）。因此本实验改用 5.1.3 / 5.1.4 的 cache / branch 事件做三角验证。

5.1.3 前端侧辅助诊断：L1-icache-load-misses / branch-misses

事件	语义	高值代表
L1-icache-load-misses	L1 指令缓存未命中次数	代码段过大或跳转太散，取指要下探更慢的层级
branch-misses	分支预测失败次数	控制流不可预测（间接调用、随机分支）

• 这两个事件刻画"前端喂不饱"的两类常见根因：取指带宽（icache miss）与控制流可预测性（branch-misses）。
• 判读规则：前端停顿高 + L1-icache-load-misses 高 → 代码布局问题；前端停顿高 + branch-misses 高 → 分支预测问题（见 5.3）。

5.1.4 后端侧辅助诊断：cache-references / cache-misses / LLC-loads / LLC-load-misses

事件	语义	高值代表
cache-references	末级缓存（LLC）访问次数（含命中与缺失）	内存子系统负载
cache-misses	末级缓存未命中次数（需下探内存）	数据布局差 / 随机访存
LLC-loads	LLC（L3）被实际加载的次数	跨核 / 跨 CCX 数据位移
LLC-load-misses	LLC 加载仍未命中、需访问内存控制器的次数	内存带宽 / 延迟瓶颈

• cache-misses / cache-references 是末级缓存缺失率；LLC-load-misses / LLC-loads 是"连 L3 都没命中"的更深一级缺失率。
• 关键陷阱：不要只看 cache-misses 占比。本实验中模式4 占比 57.9% 看着最高，但绝对数才是真瓶颈信号——模式3 的 cache-misses = 932K 是其他模式（~12K）的 75 倍，而模式4 的 12K 只是基准噪声（见 7.3.3 / 7.3.4）。

5.1.5 事件选择小结

想看"等什么"          首选事件（黄金）                  不可用时的替代（三角验证）
─────────────────────────────────────────────────────────────────────────────
前端喂不饱流水线      stalled-cycles-frontend           L1-icache-load-misses + branch-misses
后端等数据/资源       stalled-cycles-backend            cache-misses + LLC-load-misses
整体效率             IPC (=instructions/cycles)         cycles + instructions

一句话：cycles / instructions 给效率与基准时间，stalled-cycles-frontend / backend 是 PMU 区分前后端的黄金事件（本环境缺失），L1-icache / branch-misses 与 cache / LLC 系列分别在前端、后端侧做三角验证，且 cache-miss 要看绝对数而非占比。

5.2 逐个模式诊断

# 模式1: 对照组 — 预期前后端停顿都低
make perf1
# 模式2: 间接调用 — 预期 frontend >30%
make perf2
# 模式3: 随机访存 — 预期 backend >40%, cache-misses 极高
make perf3
# 模式4: 依赖链 — 预期 backend >30%, 但 cache-misses 低（无内存瓶颈）
make perf4

5.3 关键指标速查

stalled-cycles-frontend / cycles  > 30%  → 前端瓶颈
stalled-cycles-backend  / cycles  > 30%  → 后端瓶颈
前端高 + L1-icache-load-misses 高        → 代码段问题
前端高 + branch-misses 高                → 分支预测问题
后端高 + cache-misses 高                 → 数据布局问题
后端高 + cache-misses 低                 → 依赖链/ALU瓶颈

6. 预期发现

下面的预期值不是拍脑袋定的，每一项都能从 CPU 微架构事实（发射宽度、分支预测失败代价、cache/内存延迟、依赖链延迟）推导出来。表格先给一览，6.1~6.4 逐模式给出理论依据。

表 6.1 四模式预期指标一览

	模式1 纯计算	模式2 间接调用	模式3 随机访存	模式4 依赖链
IPC	>2.5	<1.0	<0.5	~0.25
frontend %	<5%	30~50%	<10%	<10%
backend %	<5%	<10%	40~70%	30~50%
cache-miss %	<1%	<5%	>30%	<1%

6.1 模式1 纯计算：理想态基线的理论依据

四条互相独立的累加链 a=a+b / b=b+c / c=c+d / d=d+a：

• IPC > 2.5：现代超标量 x86 每周期可发射 ~ 4 条整数运算（port 0/1/5/6 等端口）。四条链互不依赖 → 指令级并行（ILP）= 4。每条 add 延迟仅 1 cycle，四条链可交错发射，理想 IPC 接近发射宽度 4；实际受端口竞争、寄存器重命名带宽限制，回落到 2.5~3，故取 >2.5。
• frontend/backend < 5%：无内存访问、无间接分支，唯一的循环尾分支 i < ITERS 100% 可预测 → 取指/译码不空转、执行单元不缺数据，前后端停顿都极低。
• cache-miss < 1%：所有变量都在寄存器里，不碰任何缓存层级，cache 事件几乎为 0（仅对齐噪声）。

下图为单次迭代在µop（微指令）层面的流水线序列——四条独立链被译码成 µop 后并行入队，调度器每周期向多个执行端口派发，全程没有 µop 在 RS 里空等：

6.2 模式2 间接调用：前端停顿的理论依据

每轮一次间接调用 fns[i % NFNS](v)：

• frontend 30~50%：间接分支的目标地址来自函数指针表（内存），分支预测器（BTB）必须预测目标。当目标在 16 个函数间轮转、无局部规律时，间接分支预测失败率高。现代 x86 一次预测失败的代价约 15~20 周期的流水线冲刷；而每 ~ 5 条指令就出现一次间接调用，恢复期间取指/译码阶段空转 → 前端停顿占比被这类"取指断流"主导。经验区间 30~50%。
• backend < 10%：被调函数都是 1~3 条简单算术，执行快、无访存 → 执行单元不缺数据，后端几乎不空转。
• cache-miss < 5%：16 个函数体很小，整体大概率驻留 L1 指令缓存；但间接调用使取指地址跳跃，L1-icache 命中率略降，故写成 <5% 而非 0。

注意：这是"经典间接分支难预测"的理论预期。实测（第 7 章）发现现代 4K~16K 项 BTB 已能学下 16 项小表，故实测 IPC 远高于此——见 7.4.1。

下图为一次间接调用在 µop 层面的序列——call 被译码成一条间接分支 µop，目标需由 BTB 预测；预测失败时已在途的所有 µop 都被丢弃、前端重新取指，这正是"取指断流"的微架构本质：

6.3 模式3 随机访存：后端 cache 瓶颈的理论依据

依赖链 idx = arr[idx % N] % N + sum += arr[idx]：

• backend 40~70%：idx 的下一跳地址依赖上一次读出的 arr[idx]，CPU 必须等这次访存返回才能算下一跳 → 硬件预取器完全失效。数组 N = 16M 远超 L3，随机访问使 L1/L2/L3 全 miss，每次只能从 DRAM 取（~100ns ≈ 300 cycle @3GHz）。每轮有用指令仅索引计算 + 一次加法（几条），其余 ~300 cycle 都在等数据返回 → 后端停顿占比高。经验区间 40~70%。
• cache-miss > 30%：随机遍历 16M 元素，几乎每次 cache-references 都 miss，L3 缺失率接近 100%，保守写 >30%（实测 45.71%）。
• frontend < 10%：主循环 i < ITERS 分支高度可预测，真正的不可预测性来自 idx % N 的余数计算（被编译成 div/idiv 序列、触发数据相关分支），但它位于地址计算而非控制流主循环，不计入前端主停顿——这一项在实测中成为"意外高 branch-miss"的来源，见 7.3.3。

下图为单次访存在 µop 层面的序列——load arr[idx] 被译码成 load µop，但其地址依赖上一轮的 load 结果，于是该 µop 在调度器 RS 里干等；而缓存全 miss 让它一直等到 DRAM 返回（~300 cycle），预取器因依赖链完全失效：

6.4 模式4 依赖链：后端依赖瓶颈的理论依据

a = a * 13 + 7 每轮依赖上一轮的 a：

• backend 30~50%：串行依赖 → ILP = 1。整数乘法 imul 延迟 ~3~4 cycle、吞吐 1/cycle（依赖链受延迟而非吞吐限制）。单条串行链每 3~4 cycle 才产出 1 条结果，期间指令发射被数据依赖卡住、执行单元空转 → 后端停顿。由理论 IPC ≈ 1 / 延迟 = 1/4 = 0.25 反推，后端停顿约 (4-1)/4 ≈ 75%；但循环自增与尾分支开销可掩盖一部分，故经验区间取 30~50%。
• cache-miss < 1%：纯寄存器算术，不访问 arr → 无 cache 活动，与模式1 同源。
• frontend < 10%：循环体仅 1 条算术 + 循环尾分支，高度可预测。

注意：-O2 下 GCC 会把 a*13+7 强度削减为移位/加法链（13 = 8+4+1），把乘法延迟拆成 3 条 1-cycle 链式加法，使实测 IPC 从理论 0.25 升到 0.77——见 7.4.1。

下图为单次迭代在 µop 层面的序列——a=a*13+7 被译码成 mul µop，其源操作数依赖上一轮的 mul 结果；该 µop 在调度器 RS 里等到 ALU 延迟（3 ~ 4 cycle）结束后才能派发，于是 RS 里后续 µop 全部空等、每 3 ~ 4 cycle 才发射 1 个，且全程不碰内存：

6.5 预期值的共性推导逻辑

四个模式的预期值都遵循同一个判读框架：先判瓶颈在"前端喂不饱"还是"后端等数据"，再用具体微架构事实（分支预测代价 / 内存延迟 / 依赖链延迟）把百分比算出来。

瓶颈类型       定性信号              定量推导（理论来源）
──────────────────────────────────────────────────────────────────
前端停顿  间接分支/跳转散    分支失败代价(15~20cy) ÷ (有用指令周期+恢复周期)
后端-cache 随机/大数组访存  内存延迟(~300cy) ÷ (访存间隔有用指令周期+300cy)
后端-依赖 串行算术依赖链    运算延迟(3~4cy) ÷ (每轮总周期) → IPC≈1/延迟
理想态    多独立链/无访存    ILP=链数 逼近 发射宽度(4)

一句话：每个预期值都可由"发射宽度（模式1）、分支预测失败代价（模式2）、内存访问延迟（模式3）、依赖链运算延迟（模式4）"这四个微架构常数推导——表格里的数字不是猜测，而是 IPC ≈ 有用产出 / 等待周期 的直接结果；实测与预期的偏差（模式2/4）本身也印证了现代编译器和 CPU 的优化能力。

7. 实验数据

沙箱环境实测记录。每次跑满 SECONDS = 3 秒，perf stat 抓 8 类关键事件。

7.1 测试环境与重要限制

项	值
命令	make perf-all（逐模式 perf stat）
编译	-O2 -g（默认）
单模式时长	~3.0s wall-clock
CPU 支持 stalled-cycles-frontend/backend	否（4 个模式都 <not supported>）

由于本环境 CPU 不暴露 stalled-cycles-* 事件，无法直接看前端/后端停顿占比。本节只能通过 IPC + L1-icache-load-misses + branch-misses + cache-misses + LLC-load-misses 这五项指标做三角验证。

7.1.1 云服务器（KVM 虚拟化）实测：全部硬件指标 <not supported>

在腾讯云轻量应用服务器上复现本实验时，perf stat 的所有硬件计数器都报 <not supported>——这与上面沙箱环境（仅 stalled-cycles-* 两项缺失）不同，这里是 PMU 整体不可用。

实测诊断证据（真实输出）

检查	命令	结果	含义
是否虚拟机	systemd-detect-virt	kvm	guest 是 KVM 虚拟化
CPU 虚拟化标志	grep -o hypervisor /proc/cpuinfo	命中 hypervisor	进一步确认
硬件事件是否可用	perf stat -e cycles,instructions,cache-misses true	三项全 <not supported>	guest 内无 PMU 硬件
软件事件是否可用	perf stat -e task-clock,context-switches,page-faults true	task-clock/page-faults(=108) 正常	perf 框架本身没坏

根因：虚拟化未透传 vPMU，不是 Docker

• <not supported> 的语义是内核 PMU 驱动无法为当前环境编程出计数器；当所有硬件事件都如此，说明 guest 内核启动时根本没探测到 PMU。
• 腾讯云轻量应用服务器是 KVM + 共享型 vCPU，云厂商默认不开启 vPMU 透传（避免租户间侧信道、省虚拟化开销），guest 内看不到任何 PMU 计数器。
• Docker 不是原因：Docker 共享宿主机内核，宿主机有 PMU 容器就有；即便权限/seccomp 受限，报错也是 Permission denied / <not counted>，且软件事件会一起失效——而实测中软件事件照常工作、只有硬件计数器挂掉，恰好反证是"底层 VM 没透传 PMU"。即使真在 Docker 里，锅也在那层 KVM。
• 与沙箱环境的区别：沙箱有 PMU，仅 stalled-cycles-* 两个型号相关别名事件无映射；本机是整个 PMU 未暴露，程度更重。

能做什么 / 不能做什么

• ✅ 可用（软件事件，无需 PMU）：task-clock、cpu-clock、context-switches、cpu-migrations、page-faults/minor-faults/major-faults，以及 perf record -e task-clock 画函数级火焰图（无 cache/branch 维度）。
• ❌ 不可用（需真实 PMU）：IPC、cache-misses、branch-misses、LLC-*、stalled-cycles-* 等一切硬件计数——本实验四模式对比跑不出。
• 要复现文档硬件计数器实验，需换裸金属或支持 vPMU 透传的实例。

就地确认命令

systemd-detect-virt                                  # 期望 kvm
grep -o hypervisor /proc/cpuinfo                     # 期望命中
perf stat -e cycles,instructions,cache-misses true   # 全 not supported = PMU 未透传
perf stat -e task-clock,context-switches,page-faults true  # 软件事件正常 = perf 框架没坏
ls -la /.dockerenv 2>/dev/null                       # 是否容器内（无关根因）

一句话：云服务器上 perf 硬件指标全 <not supported>，是 KVM 未把 vPMU 透传进 guest 所致，与 Docker 无关；证据是 systemd-detect-virt=kvm 且软件事件照常工作——在此类环境只能靠软件事件（task-clock/page-faults 等）做性能分析，硬件计数器实验需换裸金属/支持 vPMU 的实例。

7.2 实测数据汇总

指标	模式1 纯计算	模式2 间接调用	模式3 随机访存	模式4 依赖链	横向对比
cycles	12,314,534,985	12,162,597,727	12,332,552,105	12,411,723,812	四模式都在 ~12.3B，几乎一致——固定跑满 3 秒，cycles 由 wall-clock 决定
instructions	27,554,963,147	22,568,666,624	6,957,327,514	9,616,659,416	模式1 最多、模式3 最少（仅 1/4）；指令数差异直接决定 IPC 高低
IPC	2.24	1.86	0.56	0.77	模式1 > 模式2 > 模式4 > 模式3，流水线每周期能跑的 µop 逐级下降
L1-icache-load-misses	67,772	50,952	30,432	46,523	量级都小（3~6.7 万），模式1 反而最高（循环体指令多），全非瓶颈
branch-misses	24,907	21,127	8,594,783	13,999	仅模式3 异常高（340~610×）；模式2 比模式1 还低→BTB 学下了 16 项目标
cache-references	25,301	22,968	2,039,690	21,720	仅模式3 频繁访问缓存层级（204 万，约 87×），其余都极少
cache-misses	12,539	11,719	932,192	12,584	模式3 是其余三者的 75 倍——唯一真 cache 瓶颈的硬证据
cache-miss 占比	49.56%	51.02%	45.71%	57.94%	看似都高（46%~58%），但绝对数小→占比失真，判瓶颈要看绝对数
LLC-loads	—	—	60,650	—	仅模式3 非零；其余工作集都在 L1/L2，到不了 L3
LLC-load-misses	—	—	19,581 (32.29%)	—	仅模式3 有值，32.29% 的 L3 命中仍下探 DRAM
吞吐（亿次/秒）	0.5	0.7	0.3	0.5	模式2 最高、模式3 最低；IPC 低但单轮轻→吞吐可反超模式1
wall-clock	3.015s	3.007s	3.012s	3.010s	都在 ~3.01s，符合"固定时间窗"设计，保证采样量一致

IPC 对比（文本柱状图，便于一眼看出数量级）：

模式1 纯计算   ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇  2.24
模式2 间接调用  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇      1.86
模式4 依赖链   ▇▇▇▇▇▇▇                  0.77
模式3 随机访存  ▇▇▇▇▇                    0.56

7.3 逐模式分析

7.3.1 模式1 纯计算（对照组 · IPC 2.24）

• IPC 最高，instructions 27.5B / 12.3B cycles ≈ 2.24，与预期 ">2.5" 接近。
• cache-misses 仅 1.25 万，几乎全是 64B 对齐的伪共享/对齐噪声。
• branch-misses 2.5 万，对应 13M 循环的循环尾分支（99.8% 准确率，预期行为）。
• 结论：达到"理想态"基线，前后端都基本无停顿。

7.3.2 模式2 函数指针间接调用（前端停顿 · IPC 1.86）

• IPC 1.86，比模式1 低 17%，但仍高于 1.0。低于"预期 <1.0"。
• 原因：本机 BTB（分支目标缓冲）实测能学 16 项小函数指针表，branch-misses 反而比模式1 还少（21K vs 25K）。间接分支的"难预测"在小表场景下被现代 BTB 缓解。
• L1-icache-load-misses 50K 略低于模式1（也是因为 16 个函数体比模式1 的纯算术更紧凑）。
• 结论：当前环境下模式2 主要受调用栈建立/返回开销拖累（每个 call 推/弹寄存器、SP 更新），而非典型的"前端喂不饱"。要在更复杂间接调用场景（如上千项虚函数表、随机跳转）才更容易复现教学文档里 <1.0 的极端值。

7.3.3 模式3 随机内存访问（后端停顿 · cache miss · IPC 0.56）

• IPC 0.56 全场最低，完全符合"后端 cache 瓶颈"预期。
• cache-misses 93 万，是其他三个模式（~1.2 万）的 75 倍——这就是瓶颈的直接物证。
• LLC-load-misses 19,581 / 60,650 = 32.29%：约 1/3 的 L3 命中也未能命中 L2/L1，必须下钻到内存控制器。
• 异常现象：branch-misses 8,594,783，比其他模式高 400 倍。原因：idx % N（N=16M，非 2 的幂）被编译器展开为 div/idiv 序列，每次迭代约触发 3~5 次条件分支，硬件分支预测器对"模 16M 余数"完全学不会；这是数据相关分支的"双停顿"副作用——既拖慢后端，又吃满分支预测器。
• 结论：是 4 个模式里唯一同时显著触发 cache 和 branch 双瓶颈的场景，对应"乱序访存"最差情形。

7.3.4 模式4 长数据依赖链（后端停顿 · 依赖 · IPC 0.77）

• IPC 0.77，显著低于模式1（2.24）但高于模式3（0.56），符合"ALU 依赖链延迟 ~4 cycles 限制 ILP=1"的理论预期。
• cache-misses 12,584 与模式1（12,539）几乎相同——纯算术循环无内存访问，cache 数据是噪声。
• branch-misses 13,999 极少，因为循环体只有 1 条 a = a * 13 + 7，没有索引、间接调用。
• 结论：定位为纯 ALU 依赖链瓶颈，与内存子系统无关——cache-misses 低、LLC-load-misses 没有显著数值，是和模式3 的关键区分点。

7.4 与理论预期的对比

模式	预期 IPC	实测 IPC	差异	解读
1 纯计算	>2.5	2.24	略低	接近基线，受 I/O / 函数调用残留影响
2 间接调用	<1.0	1.86	远高于预期	现代 BTB 缓解 16 项小表，瓶颈转移到调用栈
3 随机访存	<0.5	0.56	略高	符合 cache miss 主导瓶颈
4 依赖链	~0.25	0.77	远高于预期	a*13+7 在 -O2 下被强度削减或部分并行

7.4.1 模式2 / 模式4 实测 IPC 比预期高的原因

• 模式2 偏离预期：现代 x86 的 BTB（Branch Target Buffer）通常有 4K~16K 项，16 个目标完全能塞进去，预测准确率 95%+；这导致"间接分支预测失败"在 2026 年的服务器 CPU 上已经不容易被小表触发了。要复现 <1.0 需要：① 目标数 > 4K；② 加随机扰动（PRNG 选目标）。
• 模式4 偏离预期：a = a * 13 + 7 在 -O2 下被 GCC 强度削减（13 = 16 - 2 - 1，用移位/加减替代乘法），且可能与 a 寄存器的旁路/重命名结合出现一定的"软并行"。要复现 ~0.25 需要 volatile 锁住 a、显式调用 __builtin_ia32_imul 或更长的依赖链（如 5 次连乘）。

7.5 关键发现总结

1. 环境限制是首要前提：stalled-cycles-frontend/backend 在本沙箱不可用，必须改用 IPC + cache/branch 三角验证。
2. IPC 排序与文档预期完全一致：模式1 > 模式2 > 模式4 > 模式3，但模式2/4 绝对值因现代 CPU 微架构优化而显著高于"教学极端值"。
3. 模式3 是唯一双重瓶颈（cache + branch），且 cache-miss 绝对数比其余三者高 2 个数量级，是 4 个模式里最值得做优化的对象。
4. cache-miss 绝对数是比 IPC 更可靠的瓶颈判据：模式4 的 cache-miss 占比 57.94% 看似最高，但绝对数（12K）只是基准噪声；模式3 的 932K 才是真瓶颈。
5. 现代 CPU 的预测器很强：复现"前端停顿"经典场景需要把间接调用表放大到 4K+ 项；当前 16 项的演示强度不足以让 BTB 失效。

一句话：沙箱里 stalled-cycles-* 不可用时，IPC 排序定方向、cache-miss 绝对数量大小、LLC-load-miss 占比这三项足以三角定位瓶颈——模式3 是 cache/branch 双爆，模式4 是纯 ALU 依赖，模式1 是理想态，模式2 在现代 BTB 面前已被部分缓解。

8. 关联文档

• tools/code/perf.md——perf 工具主文档，§六.1.2 流水线停顿事件
• concepts/tools/perf-demos-architecture.md——perf 12 场景学习架构总纲
• concepts/cpu/pmu.md——PMU 硬件架构与 Stall 事件原理

一句话：IPC 低决定"有问题"，stalled-cycles-frontend vs backend 决定"问题在哪"——前端 = 指令侧，后端 = 数据侧。