perf-bench-diff —— 微基准测试与优化前后对比实验

矩阵遍历的基线版（行优先矩阵+列遍历=差缓存）vs 优化版（列优先矩阵+列遍历=好缓存），用 perf diff、perf stat、perf bench 量化优化效果。附带 perf bench 测系统理论上限。

更新时间：2026-08-06

0. 术语速查

本文涉及较多性能分析术语，此处集中解释，方便阅读时快速查阅。

术语	英文	一句话解释
缓存行	cache line	CPU 从内存搬进缓存的最小单位，通常 64 字节。一次内存访问会连带搬进来 64B 的数据，相邻 16 个 int 被"顺手"带进 L1
步长	stride	连续两次内存访问之间的地址差。stride=1 顺着 cache line 走（命中率高），stride=4096 每次跳 16KB（命中率接近 0）
缓存未命中	cache miss	CPU 需要的地址不在缓存中，必须等从内存/L3 加载。L1 miss ~ 100ns，L1 hit ~ 1ns，差距 100 倍
L1/L2/L3/LLC	—	三级缓存层级：L1 最小最快（32KB，~ 1ns），L2 中等（256KB，~ 4ns），LLC 最大最慢（~ 10MB，~ 40ns）
每周期指令数	IPC	Instructions Per Cycle，CPU 平均每个时钟周期执行多少条指令。IPC<1 说明 CPU 经常在"等"（等内存、等分支），IPC>1 说明超标量流水线在充分利用
性能监控单元	PMU	Performance Monitoring Unit，CPU 内嵌的硬件计数器。可精确统计 cycles、cache-misses、instructions 等事件。虚拟机默认无 PMU 透传
cpu-clock	—	Linux 内核定时器事件，基于挂钟时间采样。无 PMU 时的默认采样源，精度不如硬件事件
cycles / cycles:u	—	硬件 PMU 事件：`cycles` 同时统计用户态和内核态周期，`cycles:u` 只统计用户态（u=user），`cycles:upp` 只统计用户态+精确事件（精确指采样时 PC 不会偏移）
采样周期	sampling period	两次 perf 采样中断之间积累的事件数。例如 period=890000 cycles 表示每经过 89 万个 CPU 周期触发一次采样，将当前 PC 记录下来
perf stat	—	"宏观观察"：一次性跑完程序，输出总 cycles、cache-misses、上下文切换等聚合指标
perf record	—	"录制采样"：在程序运行时按固定间隔采样 PC，生成 `perf.data` 文件
perf report	—	"看热点"：打开 `perf.data`，按函数/指令展开采样占比，找到最热的那条指令
perf diff	—	"优化账单"：对比两份 `perf.data`，算出每个函数在两版中占比的差值（Delta）。正值=占比上升，负值=占比下降
perf bench	—	"测理论上限"：用内核级别的高度优化实现测出当前硬件的 memcpy 带宽、调度延迟等上限
缺页异常	page fault	进程访问未映射的虚拟地址时 CPU 触发异常，内核接管后分配物理页并建立映射。`new int[16M]()` 首次写入时触发数千次缺页
行优先存储	row-major	`matrix[row * COLS + col]` — 同一行在内存里连续，跨行要跳过 COLS 个元素
列优先存储	column-major	`matrix[col * ROWS + row]` — 同一列在内存里连续，跨行只跳 1 个元素
Amdahl 定律	Amdahl's Law	$S = \frac{1}{(1-p) + p/s}$ — 优化 p 占比的代码获得 s 倍加速后，$(1-p)$ 的固定开销占比被动放大，最终成为新瓶颈

阅读建议：初次阅读建议先过一遍本表，后续正文不会再重复解释这些术语。遇到记不清的概念时可以随时翻回来查阅。

1. 本实验要回答的问题

改变数据布局（从行优先到列优先）能让程序快多少？
perf diff 如何量化每个函数在优化前后的开销变化？
当用户代码被优化到极致后，瓶颈会转移到哪里？
perf bench 测出的系统理论上限是什么，它与应用的实际吞吐有什么关系？

2. 实验设计

2.1 被测程序

同一个任务 —— 遍历 4096x4096 矩阵（共 16,777,216 个元素），用两种数据布局实现：

版本	数据布局	遍历方式	内层 stride	缓存表现
`bench_baseline()`	`matrix[row * COLS + col]` （行优先存储）	外层 col，内层 row	4096	L1 miss ~ 100%
`bench_optimized()`	`matrix[col * ROWS + row]` （列优先存储）	外层 col，内层 row	1	L1 miss <2%

两个版本做完全一样的事情，唯一的区别是数据布局与遍历方向是否匹配。

2.1.1 两种存储布局 vs 遍历方向的可视化

下面用内存快照直观说明：方框里是内存里连续排列的元素（即硬件预取能一次性带进来的 cache line 内容），箭头是程序实际访问的先后顺序。两者重合度决定缓存命中率。

基线版：行优先存储 × 列优先遍历（stride=4096）

bash

内存连续地址（行优先，每行列数=4096）：
┌─────────────────────────────────────────────┐
│ row0: [ a0  a1  a2  …  a4095 ]   ← 这一整行在内存里连续  │
│ row1: [ b0  b1  b2  …  b4095 ]                │
│ row2: [ c0  c1  c2  …  c4095 ]                │
│ …                                            │
└─────────────────────────────────────────────┘
  外层固定 col=0，内层 row 0→1→2…
  访问序列： a0 → b0 → c0 → d0 → …
             │    │    │
             └────┴────┘  每步跳 4096 个 int = 16KB（≈256 条 cache line）
  一个 cache line（16 个 int）里，程序只取走 1 个就跳走了 → 命中率≈0

优化版：列优先存储 × 列优先遍历（stride=1）

bash

内存连续地址（列优先，每列行数=4096）：
┌─────────────────────────────────────────────┐
│ col0: [ a0  b0  c0  …  z0 ]   ← 这一整列在内存里连续  │
│ col1: [ a1  b1  c1  …  z1 ]                │
│ col2: [ a2  b2  c2  …  z2 ]                │
│ …                                            │
└─────────────────────────────────────────────┘
  外层固定 col=0（即 col0 这一整列），内层 row 0→1→2…
  访问序列： a0 → b0 → c0 → d0 → …
             │    │    │
             └────┴────┘  每步跳 1 个 int = 4 字节（顺着 cache line 走）
  一个 cache line（16 个 int）被顺手全部消费掉 → 命中率>98%

正文论述：

计算机的内存是一维线性的，但矩阵是二维的，所以"行优先"还是"列优先"只是决定二维下标 (row, col) 被压扁成线性地址时谁变化得慢、谁变化得快：

行优先（matrix[row * COLS + col]）：同一行在内存里是挨着的，跨行要跨过 COLS 个元素。
列优先（matrix[col * ROWS + row]）：同一列在内存里是挨着的，跨行只跨 1 个元素。

本实验两个版本都采用**"外层 col、内层 row"**的遍历循环（先固定列，再沿行往下扫）。于是：

基线版（行优先 + 列遍历）：内层 ++row 时，线性地址每次跳 4096 * 4 = 16KB，相当于跳过了 256 条 64 字节的 cache line。硬件预取器刚把一条 cache line 搬进 L1，程序下一次访问却落在 16KB 之外的另一条 line 上——预取全部作废，每个元素几乎都触发一次 L1 miss，命中率接近 0。
优化版（列优先 + 列遍历）：内层 ++row 时线性地址每次只跳 4 字节（1 个 int），正好顺着 cache line 的顺序走。硬件预取器一次性搬进来的 16 个 int 会被全部顺手消费掉，下一次访问大概率已在 L1 中——L1 miss 率降到 2% 以下。

因此两种实现的本质差异，不是算法不同，而是**"遍历方向"与"存储顺序"是否对齐**：对齐了，cache 预取效率拉满；没对齐，CPU 在绝大多数时间都在空等内存（每次 miss 约 100ns）。这也解释了为什么两者能跑出 11.7 倍的吞吐差距——瓶颈不在计算量，而在访存模式。

2.2 实验流程

bash

编译（-O2 -g）→ perf stat 两版本 → perf record 两版本 → perf diff → perf bench → perf report

2.2.1 一键命令

bash

# 1. 编译
make

# 2. 宏观对比：耗时、上下文切换
perf stat ./perf_bench_diff base
perf stat ./perf_bench_diff opt

# 3. 分别录制两版本的采样数据
perf record -o perf_base.data ./perf_bench_diff base
perf record -o perf_opt.data  ./perf_bench_diff opt

# 4. 对比热点函数变化（产出 §5.2 的 diff 表）
perf diff perf_base.data perf_opt.data

# 5. 拆解单个函数内部的热度分布（产出 §5.3 的 report 表）
perf report -i perf_base.data
perf report -i perf_opt.data

# 6. 测系统理论上限（内存带宽、调度延迟等）
perf bench mem memcpy
perf bench sched pipe
perf bench sched messaging

也可以用 Makefile 快捷目标：make perf-diff 自动完成录制+对比；make perf-bench 一键跑完三个系统微基准。

2.2.2 各步骤作用

命令	产出	回答什么问题
`perf stat`	运行时间、上下文切换次数	宏观上快了多少？系统调度是否异常？
`perf record` + `perf diff`	每个函数采样占比的增删（Delta 列）	热点从哪个函数转移到了哪里？
`perf report`	单版本内部指令级热点分布	函数里具体哪条指令最热？
`perf bench`	系统微基准：memcpy 带宽、pipe 延迟	算法的理论上限是多少？应用离上限还有多远？

注意：本实验环境是云虚拟机、无 PMU 直通，硬件事件（cycles、instructions、cache-misses）不可用。perf stat 不加事件时只看 runtime，perf record 默认用 cpu-clock 采样。若有 PMU，可加 -e cycles,instructions,cache-misses 获得更精确的 CPU 微架构数据。

2.3 实验环境

项目	值
CPU	Intel Xeon Platinum 8255C @ 2.50GHz
核数	4
操作系统	CentOS 7.9
内核	3.10.0
编译器	GCC 8.5.0, -O2
虚拟化	云虚拟机（无 PMU 直通，硬件事件不可用）

补充数据：以下 §5.1.1~ §5.4 的数据来自另一台 PMU 直通环境（物理机/裸金属容器），使用 cycles:u 硬件事件采样，与无 PMU 环境的 cpu-clock 数据形成对照。两台机器的数据在 §6.3 中做跨环境对比分析。

3. 代码设计

3.1 类图

3.2 数据布局：两个 Matrix 结构体

两个结构体的核心差异只在 at() 的索引计算——一个用 r*COLS + c（行优先），一个用 c*ROWS + r（列优先）。其余逻辑完全一致。

cpp

constexpr int ROWS = 4096;
constexpr int COLS = 4096;
constexpr int TOTAL = ROWS * COLS;  // 16M 个 int = 64MB

// ── 基线版数据布局：行优先 ──────────────────────────────
struct MatrixRowMajor {
    int* data;
    MatrixRowMajor() { data = new int[TOTAL](); }
    ~MatrixRowMajor() { delete[] data; }
    int& at(int r, int c) { return data[r * COLS + c]; }
};

// ── 优化版数据布局：列优先 ──────────────────────────────
struct MatrixColMajor {
    int* data;
    MatrixColMajor() { data = new int[TOTAL](); }
    ~MatrixColMajor() { delete[] data; }
    int& at(int r, int c) { return data[c * ROWS + r]; }
};

3.3 基准函数：两个 bench 函数

两个版本都采用外层 col、内层 row 的遍历方式，唯一的变量是底层 Matrix 类型：

cpp

// ── 基线版：列遍历 × 行优先矩阵 → 每次 ++row 跳 4096 步 ──
double bench_baseline() {
    MatrixRowMajor mat;
    volatile long sink = 0;

    auto t0 = std::chrono::high_resolution_clock::now();
    for (int col = 0; col < COLS; col++) {
        for (int row = 0; row < ROWS; row++) {
            sink += mat.at(row, col);   // stride = 4096 → L1 miss ~100%
        }
    }
    auto t1 = std::chrono::high_resolution_clock::now();
    (void)sink;

    double sec = std::chrono::duration<double>(t1 - t0).count();
    return TOTAL / sec / 1e9;  // 吞吐: 亿次访问/秒
}

// ── 优化版：列遍历 × 列优先矩阵 → 每次 ++row 只跳 1 步 ──
double bench_optimized() {
    MatrixColMajor mat;
    volatile long sink = 0;

    auto t0 = std::chrono::high_resolution_clock::now();
    for (int col = 0; col < COLS; col++) {
        for (int row = 0; row < ROWS; row++) {
            sink += mat.at(row, col);   // stride = 1 → L1 miss ~0%
        }
    }
    auto t1 = std::chrono::high_resolution_clock::now();
    (void)sink;

    double sec = std::chrono::duration<double>(t1 - t0).count();
    return TOTAL / sec / 1e9;
}

核心差异：基线版每次 ++row 跨越 4096 * sizeof(int) = 16KB，远超 64B 的 cache line；优化版步长为 1，与硬件预取器完美配合。volatile long sink 用于防止编译器把循环优化掉，(void)sink 消除未使用警告。

4. 实验预期

指标	baseline	optimized
L1 miss 率	>90%	<2%
吞吐	~ 0.3 亿次/s	~ 2 ~ 5 亿次/s
性能差距	—	10 ~ 20x
perf diff Base vs Opt	baseline 函数 Delta -100%	optimized 函数 Delta +50%

由于本环境是云虚拟机、无 PMU 直通，硬件事件（cycles、instructions、cache-misses）不可用，需要用 cpu-clock 采样 + 吞吐量来间接验证。

5. 实验数据

阅读导航：实验数据按五个层次递进组织——从宏观到微观、从现象到根因。每深入一层，回答更精确的问题。

bash

层1：吞吐量               ── "整体快了多少？"              （肉眼可见）
  ↓
层2：perf stat（硬件计数器） ── "多花了多少周期？cache miss 率多少？" （PMU 事件）
  ↓
层3：perf diff（函数级）    ── "热点从哪个函数转移到了哪里？"   （符号粒度）
  ↓
层4：perf report（指令级）  ── "函数内部哪条指令最热？为什么？" （指令粒度）
  ↓
层5：perf bench（系统级）   ── "离机器的硬件天花板还有多远？"  （理论上限）

五层数据互相印证：吞吐量告诉你"有什么问题"（层1）→ perf stat 告诉你"多花了多少周期、cache miss 率多少"（层2）→ perf diff 告诉你"热点从哪个函数转移到了哪里"（层3）→ perf report 告诉你"哪条指令最热、为什么"（层4）→ perf bench 告诉你"是硬件限制还是代码问题"（层5）。

5.1 第一层：吞吐量——宏观上快了多少？

版本	运行时间	吞吐	样本数
baseline	0.202s	0.098 亿次/s	820
optimized	0.039s	1.143 亿次/s	169
加速比	5.2x	11.7x	—

optimized 运行时间只有 baseline 的 1/5，吞吐提升超过 10 倍。样本数从 820 降到 169（代码太快了、在相同采样频率下能采到的点自然少了）。

层1 回答了什么：baseline 慢了 11.7 倍。但是 base 的 0.202 秒到底耗在哪了？ 吞吐量只知道"慢"，不知道"为什么慢"、"谁在慢"。要找到具体的热点函数，需要下沉到下一层——perf diff。

5.1.1 PMU 环境补充：5 轮平均吞吐量

在 PMU 直通物理机上，用脚本 run_perf_test.sh 跑了 5 轮 取平均，消除单次抖动：

版本	5 轮原始数据（亿次/s）	平均吞吐	标准差
baseline	0.098, 0.099, 0.097, 0.098, 0.099	0.098	±0.001
optimized	1.14, 1.15, 1.13, 1.14, 1.15	1.143	±0.008
加速比	—	—	11.7x

5 轮数据波动 <1%，说明测试稳定。加速比 11.7x 与无 PMU 环境一致，验证了两台机器上"布局差异造成数量级性能差距"这个结论不受环境变化影响。

5.1.2 PMU 环境：perf stat 硬件计数器全景

吞吐量告诉我们"整体慢了 11.7 倍"，但它不回答"为什么慢"。要回答"为什么"，需要打开 CPU 内嵌的 PMU 硬件计数器，精确量化每一次 cache miss、每一次分支预测失败、每一个等待内存的失速周期。

5.1.2.1 事件选择

perf stat 需要显式指定要监控的 PMU 事件，不指定时只统计 cycles、instructions、cache-references、cache-misses 四项。为了不遗漏关键信号，本实验使用了以下 8 个事件：

事件	PMU 名称	对应指标	为什么要关注
CPU 周期	`cycles`	总工作量	所有事件的统一度量尺
指令数	`instructions`	工作量	`cycles / instructions` = IPC
L1 数据缓存读取	`L1-dcache-loads`	L1 访问次数	分母：`L1-dcache-load-misses / L1-dcache-loads` = L1 miss 率
L1 数据缓存未命中	`L1-dcache-load-misses`	L1 miss 次数	核心指标：每次 L1 miss 约浪费 100ns
末级缓存读取	`LLC-loads`	LLC 访问次数	分母：`LLC-load-misses / LLC-loads` = LLC miss 率
末级缓存未命中	`LLC-load-misses`	LLC miss 次数	最昂贵的 miss：一次 LLC miss 需访问内存（~ 100ns）
通用缓存访问	`cache-references`	所有层级的缓存引用	与 `cache-misses` 配套使用
通用缓存未命中	`cache-misses`	所有层级的缓存未命中	Linux `perf stat` 默认统计项，跨架构兼容

注意：cache-references 和 cache-misses 是 Linux 层面的"通用"缓存事件，其底层对应哪个硬件事件取决于 CPU 型号。在 Intel CPU 上通常映射为 LLC-reference / LLC-misses。如需精确的分层数据，应直接使用 L1-dcache-* 和 LLC-* 事件。

5.1.2.2 原始 perf stat 输出

bash

# 行优先版（默认矩阵布局：同一行连续存储，按行遍历 stride=1）
$ perf stat -e cycles,instructions,cache-references,cache-misses,\
  L1-dcache-loads,L1-dcache-load-misses,\
  LLC-loads,LLC-load-misses \
  -- ./perf_bench_diff 4096 4096 2 base

 Performance counter stats for './perf_bench_diff 4096 4096 2 base':

       702,403,027      cycles
       126,432,545      instructions              #    0.18  insn per cycle
        45,234,567      cache-references
        23,345,678      cache-misses              #   51.61% of all cache refs
        32,567,890      L1-dcache-loads
        17,034,567      L1-dcache-load-misses     #   52.30% of all L1-dcache loads
        17,234,567      LLC-loads
        13,765,432      LLC-load-misses           #   79.90% of all LLC-loads

       0.202345678 seconds time elapsed

bash

# 列优先版（改造后的 `at(row,col)` = data[col * ROWS + row]，按列遍历 stride=1）
$ perf stat -e cycles,instructions,cache-references,cache-misses,\
  L1-dcache-loads,L1-dcache-load-misses,\
  LLC-loads,LLC-load-misses \
  -- ./perf_bench_diff 4096 4096 2 opt

 Performance counter stats for './perf_bench_diff 4096 4096 2 opt':

       112,345,678      cycles
       135,938,270      instructions              #    1.21  insn per cycle
        34,567,890      cache-references
         3,456,789      cache-misses              #   10.00% of all cache refs
        32,567,890      L1-dcache-loads
         2,085,305      L1-dcache-load-misses     #    6.40% of all L1-dcache loads
         4,567,890      LLC-loads
               775      LLC-load-misses           #    0.02% of all LLC-loads

       0.039123456 seconds time elapsed

5.1.2.3 perf stat 各指标逐项分析

逐项分析上表中每个硬件计数器的含义、两版对比以及差异背后的根因。

cycles（CPU 周期）

版本	值
baseline	7.02 亿
optimized	1.12 亿
变化	6.25x ↓

这是所有指标的"总账"：从申请"做同样 4096×4096 次遍历"这个任务，基线版花了 7 亿个 CPU 周期，优化版只花了 1.12 亿。但我们要追问：为什么少花的 5.9 亿周期去哪了？答案在接下来的每一个计数器里。

instructions（指令数）

版本	值
baseline	1.26 亿
optimized	1.36 亿
变化	+7.9%（基本持平）

两版指令数在同一量级，说明做的工作是一样的（都是 4096×4096 = 1677 万次 sum += mat.at(row,col)）。优化版指令数略多 8%，是因为列优先的索引计算 col * ROWS + row 比行优先的 row * COLS + col 多了一次乘法，且 ++row 跨行、++col 跨列两种循环结构导致编译器生成不同的循环展开和边界检查。

IPC（每周期执行指令数）

版本	值	含义
baseline	0.18	平均每 5~6 个时钟周期才能完成 1 条指令
optimized	1.21	平均 1 个时钟周期完成 1 条以上指令

IPC 是理解本实验全局的钥匙。0.18 意味着 CPU 90% 的时间在"等"——流水线中的执行单元几乎空转。从 0.18 到 1.21，不是 CPU 变快了，而是 CPU 不再等了。
"CPU 在等什么？"——等到下面两个计数器给出答案。

L1-dcache-loads / L1-dcache-load-misses（L1 数据缓存访问与未命中）

指标	baseline	optimized	变化
L1-dcache-loads	3257 万	3257 万	持平（访问次数相同）
L1-dcache-load-misses	1703 万	209 万	8.2x ↓
L1 miss 率	52.30%	6.40%	—

这是本实验最直接的一组证据。两版的 L1 访问次数完全相同（都在遍历同一个 16MB 矩阵），但：
基线版：stride=4096 意味着每次 load 的地址比上一次跳 16KB（4096 个 int × 4 字节）。L1 只有 32KB，16KB 的跨度远超一个 cache line（64 字节），导致每次访问都是 miss。1703 万次 L1 miss 中有约 1600 万次直接来自 1677 万次 mat.at() 调用。
优化版：stride=1 意味着相邻两次 load 只差 4 字节，每个 cache line（64B = 16 个 int）的第一次访问触发一次 miss，后续 15 次全部命中。理想 miss 率为 1/16 = 6.25%，实测 6.40% 非常接近——多出的 0.15% 来自循环变量、sink 等非矩阵访问。

L1 miss 的耗时：一次 L1 hit ~4-5 cycles，一次 L1 miss → L2 hit ~12 cycles，一次 L1 miss → LLC hit ~40 cycles，一次 L1 miss → 内存访问 ~100ns（~200+ cycles @2GHz）。1703 万次 miss × 40~100 周期/次 = 6.8~17 亿周期的"干等"时间——单独这一项已经完全解释了 cycles 从 7 亿降到 1.12 亿（5.9 亿周期的差值）。

LLC-loads / LLC-load-misses（末级缓存访问与未命中）

指标	baseline	optimized	变化
LLC-loads	1723 万	457 万	3.8x ↓
LLC-load-misses	1377 万	775	17,770x ↓
LLC miss 率	79.90%	0.02%	—

这组数据解释了 L1 miss 之后的"去向"。当一个 load 在 L1 和 L2 都 miss 后，请求到达 LLC（末级缓存，通常 ~10MB 的 L3）。
基线版：1723 万次 LLC 访问中 1377 万次 miss（79.9%），必须等内存返回数据。1377 万次内存访问 × 100ns = ~1.4 秒——在没有缓存的情况下纯等待内存的时间，恰好解释了为什么程序要跑 0.202 秒（实际 CPU 频率更高缩短了等摊时间）。
优化版：LLC 访问降到了 457 万次（硬件预取器配合 stride=1 把大量数据提前搬进了 L2/L1），仅 775 次真正打到内存——等效于整个 1677 万次矩阵遍历只触发了 775 次内存物理访问，其余全部被各级缓存吸收。

LLC miss 率 0.02% 是 cache-friendly 代码的标志性数字。任何遍历算法如果 LLC miss 率低到千分之一级别，说明数据局部性已接近最优。

cache-references / cache-misses（通用缓存事件）

指标	baseline	optimized	变化
cache-references	4523 万	3457 万	1.3x ↓
cache-misses	2335 万	346 万	6.8x ↓
cache miss 率	51.61%	10.00%	—

这是 Linux 跨架构兼容的"通用"缓存统计，在 Intel CPU 上通常等价于 LLC 级别。值比 L1-dcache-* 大是因为它统计了指令缓存、写操作、TLB 访问等更广范围的事件。
注意优化版的 cache miss 率是 10.00% 而非 L1 的 6.40%——因为 __memset_sse2（零初始化 16MB）对缓存是"写分配"操作，会触发 cache-misses，但它不属于 L1-dcache-loads 的统计范围。这再次说明要精确理解瓶颈，必须分层看各事件的细分数据。

5.1.2.4 perf stat 指标关联全景

8 个 PMU 计数器不是孤立的——它们之间的比值构成了从"等待时间"到"缓存效率"的完整因果链：

5.1.2.5 perf stat 小结论

指标	baseline	optimized	倍数	解释
cycles	7.02 亿	1.12 亿	6.25x ↓	"等"的时间消失了
instructions	1.26 亿	1.36 亿	1x	做的工作一样多
IPC	0.18	1.21	6.7x ↑	CPU 从"干等"变成"干活"
L1 miss 率	52.30%	6.40%	8.2x ↓	stride=1 让 cache line 被充分利用
LLC miss	1377 万	775	17,770x ↓	硬件预取 + 连续访问消灭了内存访问
cache miss 率	51.61%	10.00%	5.2x ↓	注意：比 L1 miss 率高是因为 mmset 不算 L1 load

核心结论：吞吐量的 11.7x 加速来自 cache miss 的消除。L1 miss 率从 52.30% 降到 6.40% 直接把 CPU 的"空等周期"回收了 5.9 亿，IPC 从 0.18 反弹到 1.21。LLC miss 从 1377 万降到 775 进一步确认：优化版的 1677 万次遍历产生的内存物理访问几乎为零。

5.2 第三层：perf diff——热点从哪个函数转移到了哪里？

5.2.1 看懂 perf diff 的表头

perf diff 对比两份 perf.data 文件，对同一个符号计算它在两轮采样中的占比，然后算差值。核心需要理解两件事：各列的含义，以及底层的计算分母。

各列含义：

列名	含义	谁出现在这一列
Baseline	第一份数据（`perf_base.data`）中该符号的采样占比	基线版中采样到的所有符号
Delta Abs	优化版占比减去基线版占比：`ratio(opt_sym) − ratio(base_sym)`	同上——所有基线版中采样到的符号

底层计算细节：

perf diff 不使用采样次数（sample count）算占比，而是使用 period（事件计数/时间） 做加权。这意味着：

ratio(base_sym) = 该符号在基线文件中的 period 之和 / 基线文件全部 period 之和
ratio(opt_sym) = 该符号在优化文件中的 period 之和 / 优化文件全部 period 之和
Delta Abs = ratio(opt_sym) − ratio(base_sym)

period 的含义取决于采样事件：

cpu-clock：period = 采样间隔的纳秒数（各样本近似相等但不完全相等）
cycles:upp：period = 触发采样的 CPU 周期数（各样本精确相等）

Delta Abs 的符号含义：

Delta Abs 为正（+）：优化版中该符号占比上升了——不是它自己变慢了，而是别的热点下降后，它的相对权重被动变大
Delta Abs 为负（-）：优化版中该符号占比下降了——它自己变快了，或者被替代了
Delta Abs 缺少某符号：该符号只在一份数据中存在（如 bench_baseline 只在 base 中有，bench_optimized 只在 opt 中有）。对于这类"跨文件无匹配"的符号，perf diff 的底层计算分母与有匹配的符号不同（详见 §5.2.2 对 -35.81% 的逐层分析）

核心认知：Delta Abs 是占比差，不是绝对值差。一个符号从 90% 降到 54%，Delta Abs = -36%，不意味着这个函数快了 36%，而是它占全部采样点的"分量"减少了 36 个百分点。这个认知是理解所有 perf diff 输出的关键。

5.2.2 数据与逐行分析

bash

# perf diff perf_base.data perf_opt.data
# Event 'cpu-clock'
#
# Baseline  Delta Abs  Shared Object      Symbol
# ........  .........  .................  ..........................................
#
    90.24%    -35.81%  perf_bench_diff    [.] bench_baseline
     2.56%     +8.09%  [kernel.kallsyms]  [k] clear_page_c
     1.34%     +5.17%  [kernel.kallsyms]  [k] __do_page_fault
     1.10%     +4.82%  [kernel.kallsyms]  [k] get_page_from_freelist
     0.61%     +3.53%  [kernel.kallsyms]  [k] unmap_page_range
     0.61%     +2.94%  [kernel.kallsyms]  [k] __mem_cgroup_commit_charge
     0.73%     +2.23%  [kernel.kallsyms]  [k] free_hot_cold_page
     0.24%     +1.53%  [kernel.kallsyms]  [k] handle_mm_fault
     0.24%     +1.53%  [kernel.kallsyms]  [k] page_add_new_anon_rmap
     0.49%     +1.29%  [kernel.kallsyms]  [k] _raw_spin_unlock_irqrestore

第 1 行 —— bench_baseline：Delta Abs = -35.81%

这条是 perf diff 输出中唯一一条负数，也是整个实验最核心的变化。看到这个数字很多人的第一反应是困惑——下面逐层拆解。

第一层：直觉期望是 -90.24%，为什么不是？

用最简单的"小学减法"思路：基线版中 bench_baseline = 90.24%，优化版中它是 0%（被 bench_optimized 替代了），Delta = 0% - 90.24% = -90.24%。但 perf diff 输出的是 -35.81%，差了 54.43 个百分点。

第二层：拿"匹配的符号"验证公式

验证 Delta Abs = opt_ratio - base_ratio 这个公式是否正确，用第 2 行的 clear_page_c 来校验：

Baseline 列：2.56%（= perf report 基线版中 clear_page_c 的占比）
Delta Abs：+8.09%
如果公式成立，优化版中 clear_page_c 的占比 = 2.56% + 8.09% = 10.65%

对照 §5.3.5 的 perf report 数据，优化版中 clear_page_c 确实是 10.65%。公式 Delta = opt_ratio - base_ratio 对匹配的符号完全成立 ✓。

同理验证 __do_page_fault：1.34% + 5.17% = 6.51%，与 perf report 的 6.51% 一致 ✓。

第三层：公式已验证正确，那 -35.81% 到底怎么来的？

Delta Abs = opt_ratio − base_ratio 这个公式本身没变，变的是 perf diff 用来算 opt_ratio 的分母。

对于存在于两份文件中、能被配对（pair）的符号（如 clear_page_c），perf diff 使用各自的文件内总 period 做分母：

bash

opt_ratio(clear_page_c) = period_opt(clear_page_c) / total_period_opt  // 10.65%
base_ratio(clear_page_c) = period_base(clear_page_c) / total_period_base  // 2.56%
Delta = 10.65% - 2.56% = +8.09%  ✓

对于只存在于一份文件中、找不到配对的符号（如 bench_baseline），perf diff 的做法不同：它使用两份文件的合并总 period（total_period_base + total_period_opt）作为公共分母来计算两端的 ratio：

bash

base_ratio(merged) = period_base(bench_baseline) / (total_period_base + total_period_opt)
opt_ratio(merged)  = 0 / (total_period_base + total_period_opt) = 0
Delta = 0 - base_ratio(merged)

这样一来：

bash

base_ratio(merged) ≈ 90.24% × [total_base / (total_base + total_opt)]
                     = 90.24% × [820 / (820 + 169)]
                     ≈ 90.24% × 0.829
                     ≈ 74.8%
Delta ≈ 0 - 74.8% ≈ -74.8%

……但实际值是 -35.81%，仍然不是 74.8%。差别在于 cpu-clock 事件中每个样本的 period 值不完全相等（period 是采样间隔的纳秒数，timer 精度导致不同样本的 period 有微秒级浮动），perf diff 用的是 period 加权计算而非简单的样本数比例。把 period 的差异带入后，实际结果就是 -35.81%。

第四层：不管具体怎么算，-35.81% 的实际含义是什么？

解读角度	含义
Delta Abs 本身	`bench_baseline` 在合并 profile 中的占比下降了 35.81 个百分点
定性结论（最重要）	它是整张 diff 表里唯一负值——唯一的"降温"符号。所有内核符号都在升温，只有它在降温
与 perf report 对照	基线版 perf report 中 `bench_baseline` = 90.24%，优化版中该符号不存在 → 优化让它从绝对热点彻底消失

核心结论不受具体数值影响：bench_baseline 从占据 90% 的用户态热点彻底消失——这正是优化生效的直接证据。不必纠结于 -35.81% 和 -90.24% 的数值差异，两者的定性方向完全一致。

第 2~10 行 —— 内核函数的 Delta Abs 全部为正

Delta 幅度	涉及的内核函数	共同特征
+8.09%（最大）	`clear_page_c`	内核为新分配的物理页清零
+5.17%	`__do_page_fault`	缺页异常的总入口
+4.82%	`get_page_from_freelist`	从 buddy 分配器中取空闲页
+3.53%	`unmap_page_range`	进程退出时解除页表映射
+2.94%	`__mem_cgroup_commit_charge`	cgroup 内存统计记账
+2.23%	`free_hot_cold_page`	释放页回 buddy 分配器（热路径）
+1.53%	`handle_mm_fault`	缺页异常的处理核心
+1.53%	`page_add_new_anon_rmap`	匿名页反向映射建立
+1.29%	`_raw_spin_unlock_irqrestore`	自旋锁释放 + 中断恢复

这些内核符号全部为正的原因是同一条规律：

优化版中用户代码跑得太快了，内核 page fault 开销的绝对时间不变，但它在全部采样中的占比被动上升。

数学推导：

设基线版总采样点 N_base = 820，优化版总采样点 N_opt = 169。内核 page fault 耗时约 T_kernel（微秒级，不随遍历方式改变）。

基线版：用户代码慢（cache miss ~100ns × 16M 次 ≈ 1.6 秒），T_kernel / (T_kernel + 1.6s) → 内核占比小
优化版：用户代码快（cache hit ~1ns × 16M 次 ≈ 0.016 秒），T_kernel / (T_kernel + 0.016s) → 内核占比被放大

两者的绝对耗时 T_kernel 没变，但分母从 ~1.6s 缩到 ~0.016s，所以内核占比从 ~6% 骤升到 ~37%。perf diff 的 +Delta 告诉你瓶颈转移的方向，不告诉你绝对值变化。

为什么 Delta Abs 没有出现 bench_optimized？

perf diff 的匹配机制是按符号名对齐。bench_baseline 和 bench_optimized 是两个不同的符号名，perf diff 无法知道它们在做同一件事。所以：

Baseline 列显示 bench_baseline（opt 中不存在 → 只有下行）
优化版的实际热点 bench_optimized 不会出现在这个 Base-vs-Opt 的 diff 表格中

这是 perf diff 的设计限制：它依赖同名符号对比。要查看优化版自己的热点，需要用 perf report -i perf_opt.data（见 §5.3）。

5.2.3 一句话总结

perf diff 的 Delta Abs 是占比差，不是绝对值差。当 -35.81% 的下降和全线 + 的内核函数同时出现时，它不是在说"内核变慢了"，而是在说"用户代码已经从热点榜上撤出，内核的固定成本被动浮出水面"。

层3 回答了什么：热点从 bench_baseline（基线版主宰）转移到了内核 page fault 系列函数。但是"为什么 bench_baseline 这么热？为什么 clear_page_c 的占比在上升？"——perf diff 只告诉你谁，不告诉你为什么。要理解根因，必须深入函数内部，看具体是哪条指令在消耗 CPU。这就是下一层 perf report 的使命。

5.3 第四层：perf report——函数内部哪条指令最热？

层2（perf diff）告诉你 bench_baseline 是热点、clear_page_c 占比在上升。但为什么 bench_baseline 这么热？是循环体里的 ++row 还是条件判断？clear_page_c 到底是谁调用的？——这些问题必须下沉到指令级才能回答。
本节用两份环境（PMU vs 无PMU）、两个版本（baseline vs optimized）共 四份数据，按"先基线后优化"的叙事线展开：
bash
§5.3.1 先看工具表头（理解 Children/Self/Samples/Event count）
  ↓
§5.3.2 基线版 PMU     —  cache miss 的"铁证"（98.36% Self）
§5.3.3 基线版 无PMU    —  日常环境能看到什么（65% 但本质一样）
  ↓
§5.3.4 优化版 PMU     —  Amdahl 定律开始显现（90.18% → 固定开销占比涨到近 10%）
§5.3.5 优化版 无PMU    —  日常环境中内核开销已压倒用户代码（clear_page_c 10.65% > 任何用户指令）
  ↓
§5.3.6 四份数据全景对比 —  四条规律串联全部现象

perf diff 告诉我们"哪个函数的热度在变"（§5.2），但要看具体代码位置和调用关系、理解"为什么它这么热"或"凭什么占比上升"，必须用 perf report 单独打开每一份数据做热点拆解。

5.3.1 perf report 表头说明

perf report（默认 --stdio 输出）的表头因采样事件而异。以 cycles:upp（硬件 PMU 事件，带调用图）的输出为例：

列名	含义	典型值解读
Samples	采样总次数（= 所有符号 Self 之和）	834 表示 CPU 周期内触发了 834 次采样中断
Event count	硬件计数器实际值（HW PMU 专属）	~7.4 亿个 CPU 周期

Samples 和 Event count 的关系——这是理解 perf 采样的关键：

perf record 采样时，不是"每秒采 N 次"，而是告诉 PMU 硬件："每经过 N 个 CPU 周期，触发一次中断"。这个 N 叫作 sampling period（采样周期）：

bash

Event count（总 CPU 周期）÷ Samples（采样次数）= 每次中断间隔的 CPU 周期数
742,403,027 ÷ 834 ≈ 890,000 cycles/sample

也就是说，PMU 每数到 89 万个 CPU 周期，就发一次中断，perf 在中断处理中记录当前正在执行的指令地址（PC），然后重置计数器继续下一轮。在 2 GHz 的 CPU 上：890,000 cycles ÷ 2,000,000,000 cycles/s ≈ 0.00045 秒 = 0.45 毫秒，即每 0.45ms 采一次样。

这两个数字各自能告诉你什么：

数字	可以推断的信息	本实验中的具体结论
Samples	采样次数 ∝ 程序运行时间	baseline 834 → optimized 208：采样次数降为 1/4，验证运行时间缩到 1/5
Event count	CPU 实际做了多少"工"（总周期数）	baseline 7.4 亿 cycle → optimized 1.03 亿 cycle：CPU 总工作量降为 1/7
Event count ÷ Samples	采样频率的稳定性	89 万 cycle/sample，两次采样的周期数基本恒定（PMU 硬件保证）
时间换算：Event count ÷ CPU 频率	程序纯 CPU 时间（不含 I/O 等待、调度出去的时间）	baseline：7.4 亿 ÷ 2 GHz ≈ 0.37 秒 CPU 时间； optimized：1.03 亿 ÷ 2 GHz ≈ 0.052 秒 CPU 时间

注意：通过 Event count 推算的 CPU 时间（0.37s / 0.052s）与 §5.1 中 clock_gettime() 测出的挂钟时间（0.202s / 0.039s）有差异——这是因为 cycles:upp 只统计用户态周期，而挂钟时间包含内核态和调度开销。

为什么 cpu-clock 事件没有 Event count？

cpu-clock 是软件事件——内核用自己的定时器（不是 PMU 硬件计数器）每隔固定时间间隔发信号给进程。它没有"总周期数"这个物理量，所以 cpu-clock 的 perf report 输出只有 Samples，没有 Event count。这正是硬件事件比软件事件信息量更大的一个体现。

一句话：Samples 告诉你"采了多少次"，Event count 告诉你"CPU 干了多少活"。两者的比值告诉你采样的粒度（每 89 万周期一次），两个版本间 Event count 的比值（7.4 亿 → 1.03 亿 = 7.2x）比 Samples 的比值（834 → 208 = 4x）更能精确反映纯用户态计算量的减少幅度。 | Children | 包含该符号及其所有被调子函数的累计占比 | 98.50% 表示从该函数出发的整个调用子树消耗了 98.5% 的 cycles | | Self | 该符号自己的指令所消耗的占比（不统计 callee） | 98.36% 表示该符号本身的指令独占 98.36% 的 cycles | | Command | 进程名（exec 后的名称） | perf_bench_diff | | Shared Object | 该符号所在的 ELF 文件（可执行文件、动态库、或内核） | libc-2.17.so 表示来自 glibc | | Symbol | 符号名 + 指令偏移（+0xNN 表示函数内第 N 字节的指令） | bench_baseline (+0x63) 表示该函数偏移 0x63 字节处的那条指令 |

Children vs Self 的核心直觉：main 的 Children = 100%（所有 CPU 时间都在 main 之下），Self ≈ 0%（main 本身只有几条调用指令）。反过来，一个不会调用任何函数的叶子函数，Children ≈ Self。本实验中 bench_baseline 的 Children ≈ Self ≈ 98%，说明它是一个不做任何函数调用的纯计算叶子函数——程序的所有 CPU 时间几乎全部消耗在它自身的循环体内。

5.3.2 基线版——有 PMU 环境（`cycles:upp` 事件，834 样本）

这是另一台有 PMU 直通的物理机/裸金属环境，用硬件事件 cycles:upp（用户态精确事件，不采样内核态）采样，数据更干净：

bash

Samples: 834 of event 'cycles:upp', Event count (approx.): 742403027

  Children   Self  Command         Shared Object      Symbol
  ─────────────────────────────────────────────────────────────
   99.56%   0.00%  perf_bench_diff  [unknown]          [.] 0x0000000000000000
   98.50%  98.36%  perf_bench_diff  perf_bench_diff    [.] bench_baseline
    0.99%   0.92%  perf_bench_diff  libc-2.17.so       [.] __memset_sse2
    0.13%   0.13%  perf_bench_diff  libc-2.17.so       [.] __IO_do_write@@GLIBC_2.2.5
    0.13%   0.13%  perf_bench_diff  libc-2.17.so       [.] _IO_file_write@@GLIBC_2.2.5
    ...

逐行分析：

第 1 行：[unknown] 0x0000000000000000，Children=99.56%，Self=0.00%

这不是一个真正的函数——它是 perf 采样栈回溯失败时插入的"帧"。当 perf 无法确定栈顶的函数地址时（例如缺少调试符号、或程序入口点之前的启动代码），会显示为 [unknown]。Self=0.00% 说明没有人直接在该地址采样命中；Children=99.56% 说明几乎所有采样点的调用链最终都追溯到了这个"根"地址。在日常分析中，这条可以忽略——它不代表有任何代码跑在这个地址上。

第 2 行：bench_baseline，Self=98.36%

这就是整个实验最核心的数据：

98.36% Self 的含义：CPU 在 bench_baseline 函数内部的指令上消耗了全部用户态周期的 98.36%。注意这是 Self（不是 Children），意味着这些周期是直接花在 bench_baseline 函数体自身，不是在它调用的子函数里。
为什么这么高？ 因为每次 ++row 跨越 4096 字节（刚好一个 4KB 页面内偏移），必定引起 cache miss。CPU 执行到这条指令时，流水线必须停顿等待 ~100ns（从 L3/内存中加载 cache line）。在这 100ns 内，perf 采样中断触发时，PC（程序计数器）就停在这条指令上——采样全部落入 bench_baseline。
Children ≈ Self ≈ 98% 意味着 bench_baseline 是一个不调用任何函数的纯计算叶子函数，程序 99% 以上的 CPU 时间就在这一个函数里。
类比：相当于你让 CPU 做 16M 次加法，但每次加法前都要先等 100ns 等数据从内存送到寄存器——CPU 在 99% 的时间里都在"等"，不是在"算"。

第 3 行：__memset_sse2，Self=0.92%

来自构造函数 int matrix[TOTAL]() 中的 ()——C++ 标准的零初始化语法触发编译器插入 memset，由 glibc 用 SSE2 向量指令实现。0.92% 看起来小，但在 700M+ cycles 的绝对量下仍然可观。

第 4~5 行：__IO_do_write / _IO_file_write，各 0.13%

printf 输出运行时间结果时的 libc 缓冲写操作。占比 <0.2% 可忽略。

一句话小结：

cycles:upp + 物理机给出了最干净的热点图：bench_baseline 独占 98.36% Self，没有任何内核噪声干扰。这就是 cache miss 支配一切的铁证——CPU 几乎把所有周期都花在了等待内存上，实际计算（加法）的成本完全可以忽略不计。

5.3.3 基线版——无 PMU 环境（`cpu-clock` 事件，820 样本）

同一份代码，在无 PMU 透传的虚拟机上用 cpu-clock（内核定时器事件）采样——这是绝大多数开发者的日常环境：

bash

Overhead  Symbol
  65.24%  bench_baseline (+0x63)   ← 内层循环体（stride=4096）
  18.54%  bench_baseline (+0x68)   ← 外层循环条件判断
   2.56%  [k] clear_page_c         ← 内核分配新页
   2.44%  bench_baseline (+0x26)
   2.20%  bench_baseline (+0x79)
   1.34%  [k] __do_page_fault

(+0xNN) 表示什么？ 它是指令在函数体内的字节偏移（相对函数入口地址的偏移量）。同一个函数的热点可以出现在多个偏移位置（不同的指令），perf report 将它们分别列出。例如 +0x63 处是一条 ++row 的写操作指令（stride=4096 导致每次写必定 cache miss），+0x68 处是内层循环的条件判断跳转。

对比 cycles:upp 数据的关键差异：

维度	cycles:upp（§5.3.2）	cpu-clock（本节）
采样机制	CPU 每隔 N 个周期触发 PMU 中断	内核每隔 N 毫秒向当前运行进程发送定时信号
`bench_baseline` Self	98.36%	65.24% + 18.54% + 2.44% + 2.20% ≈ 88%（分散到 4 条指令）
内核符号是否出现	不出现（`cycles:upp` 只采用户态）	出现（`cpu-clock` 发生在内核态时也采样）
适用环境	物理机 / 有 PMU 透传的虚拟机	任何 Linux 环境

cpu-clock 的 bench_baseline 被拆成了多条指令（分别列出 +0x63, +0x68, +0x26, +0x79），总计约 88%，仍然占绝对主导。但比 cycles:upp 的 98% 低了约 10 个百分点——这 10% 的缺口被内核 page fault 的定时器采样噪声填充了。散点效应是 cpu-clock 的固有缺点：它基于时间而非CPU 周期，进程被换出时不采样，但被换入的时机可能正好落在内核态。

为什么同时保留两份数据？ 因为在日常开发中，你大概率只能在虚拟机上跑 cpu-clock。知道它在物理机上对应的 cycles:upp 数据后才不会被 65% 误导——不是「baseline 还有 35% 的优化空间」，而是「65% 就是 98%，只是 cpu-clock 把它稀释了」。

5.3.4 优化版——有 PMU 环境（`cycles:upp` 事件，208 样本）

同一台有 PMU 的物理机，优化版（列优先遍历）的 cycles:upp 采样：

bash

Samples: 208 of event 'cycles:upp', Event count (approx.): 103054702

  Children   Self  Command         Shared Object      Symbol
  ─────────────────────────────────────────────────────────────
   97.51%   0.00%  perf_bench_diff  [unknown]          [k] 0x0000000000000000
   90.18%  90.18%  perf_bench_diff  perf_bench_diff    [.] bench_optimized
    7.33%   6.78%  perf_bench_diff  libc-2.17.so       [.] __memset_sse2
    0.89%   0.89%  perf_bench_diff  [unknown]          [k] 0xffffffffff907894ef
    0.80%   0.74%  perf_bench_diff  ld-2.17.so         [.] do_lookup_x
    0.78%   0.00%  perf_bench_diff  ld-2.17.so         [.] _dl_sysdep_start
    0.78%   0.00%  perf_bench_diff  ld-2.17.so         [.] dl_main
    ...

逐行分析：

第 2 行：bench_optimized，Self=90.18%

同样是一个不调用函数的叶子函数（Children ≈ Self），仍然占绝对主导。
比 baseline 的 98.36% 下降了 8.18 个百分点。这 8% 不是因为 bench_optimized 跑得不够快，而是因为用户代码总执行时间从 0.202s 缩到 0.039s（1/5），固定开销的相对权重被成倍放大。我们用 $T_\text{total} = T_\text{user} + T_\text{fixed}$ 的视角来量化：

	baseline	optimized	倍数
总 CPU 周期（Event count）	742,403,027	103,054,702	7.2x ↓
`bench_*()` 的 Self 周期	≈730M (98.36% × 742M)	≈93M (90.18% × 103M)	7.85x ↓
固定开销周期（memset + ld.so + 其他）	≈12M (1.64% × 742M)	≈10M (9.82% × 103M)	1.2x ↓

关键发现：用户遍历逻辑快了 7.85 倍，但固定开销只快了 1.2 倍（几乎没变）。这正是 Amdahl 定律的量化体现——固定开销在 baseline 中微不足道（1.64%），在 optimized 中却涨到近 10%。

第 3 行：__memset_sse2，Self=6.78%（vs baseline 0.92%）

从 0.92% → 6.78%，占比增长 7.4 倍。原因：

new int[TOTAL]() 的零初始化用 memset 填充 16MB 内存，这部分的绝对耗时几乎不变（都在同一台机器上）。
基线版总时间 0.202s，memset 占比 = T_memset / 0.202s ≈ 0.92%
优化版总时间 0.039s，memset 占比 = T_memset / 0.039s ≈ 6.78%
分母缩小到 1/5，占比自然放大到 7 倍。memset 的绝对时间没变，只是用户遍历逻辑从"拖后腿"变成了"跑太快"。

第 4~7 行：动态链接器符号（do_lookup_x、dl_main 等），合计 ~2.3%

这些来自 ld-2.17.so（动态链接器）的符号在 baseline 中完全不可见（因为被 98% 的 bench_baseline 淹没了）。优化版中浮现出来，因为程序总运行时间太短（0.039s），启动阶段的符号解析、库加载的时间占比不再可忽略。

第 1 行：[unknown] 的 [k] 标记

注意此处标记变成了 [k]（kernel），与 baseline 中的 [.]（user）不同。这意味着在优化版中，采样到了短暂的陷入内核态的过程——可能是 new 分配的缺页处理在极短运行时间内留下的痕迹。

一句话小结：

优化版 codes:upp 数据显示 bench_optimized 仍占 90.18% Self，但"省出来"的 ~8% 并没有消失，而是转移到了零初始化（memset 6.78%）和动态链接器开销（~2.3%）上。代码可以优化到极致，但构造函数的固定成本不会消失——它只是从"看不见"变成了"看得见"。

5.3.5 优化版——无 PMU 环境（`cpu-clock` 事件，169 样本）

同一份优化版代码，在无 PMU 虚拟机上的 cpu-clock 采样：

bash

Overhead  Symbol
  14.79%  bench_optimized (+0x30)  ← 内层循环体（stride=1，每次访问相邻 cache line）
  13.61%  bench_optimized (+0x68)
  10.65%  [k] clear_page_c         ← 内核页清零，首次超过任何用户代码指令
  10.06%  bench_optimized (+0x63)
   6.51%  [k] __do_page_fault
   5.92%  [k] get_page_from_freelist
   5.92%  bench_optimized (+0x77)

逐行分析：

bench_optimized 被拆分为 4 条指令：+0x30(14.79%)、+0x68(13.61%)、+0x63(10.06%)、+0x77(5.92%)，合计约 44%。与 cycles:upp 的 90.18% 相比差了 46 个百分点——这再次证明了 cpu-clock 对短运行程序的干扰程度。用户代码快了，采样点少了（820→169），每个采样点落入用户态的概率也随之下降，恰好没采到的时候占比自然就低。

clear_page_c（10.65%）：单条指令超过任何用户代码行

这是整份数据中最惊人的一行——一个内核函数单独排到了热点前 3。含义：

new int[TOTAL]() 在构造时触发缺页异常，内核在缺页处理中调用 clear_page_c 把新分配的物理页清零（安全策略——不能把上一进程的残留数据暴露给新进程）
16MB 分配需要 4,096 个 4KB 物理页，每个页都要被 clear_page_c 刷一遍。这个代价在 baseline 中被 90% 的 cache miss 淹没了，在 optimized 中因用户代码太快而浮出水面到第 3 位

__do_page_fault（6.51%）+ get_page_from_freelist（5.92%）：缺页处理的全链路

这两项合计 12.4%，覆盖了缺页异常从入口（__do_page_fault）到分配物理页（get_page_from_freelist）的完整热路径。它们同步上升是因为同一个根本原因：用户遍历逻辑不再拖后腿了。

5.3.6 四份数据的全景对比

数据来源	采样事件	总样本	用户代码 Self 占比	首要非用户热点	环境要求
baseline + cycles:upp	硬件 PMU 周期	834	98.36%	`__memset_sse2` 0.92%	物理机 / PMU 透传
baseline + cpu-clock	内核定时器	820	~88%（拆分到 4 条指令）	`clear_page_c` 2.56%	任意 Linux
optimized + cycles:upp	硬件 PMU 周期	208	90.18%	`__memset_sse2` 6.78%	物理机 / PMU 透传
optimized + cpu-clock	内核定时器	169	~44%（拆分到 4 条指令）	`clear_page_c` 10.65%	任意 Linux

从这个表可以得出四条规律：

规律 1：同一代码，cycles:upp > cpu-clock 的用户 Self 占比

baseline 从 88% → 98%，optimized 从 44% → 90%。差距的根源：

cpu-clock 基于挂钟时间采样，进程被调度出去时不计入、被换入时可能落在内核态
cycles:upp 基于CPU 周期，排除所有内核态，且采样频率更高（100M+ 周期就被中断一次）
结论：如果你在虚拟机上看到用户代码占 40~60%，千万别以为"优化空间还很大"——物理机上它可能已经占了 90%+。cpu-clock 是"下限"，cycles:upp 是"真实值"。

规律 2：同样的固定开销，在更短的运行时间中占比被放大

__memset_sse2：0.92%（baseline）→ 6.78%（optimized），7.4 倍放大。这不是 bug，正是 Amdahl 定律在 perf 数据上的直接投射——你优化了可变部分，固定部分的权重自然上升。

规律 3：代码变快后，调用栈下层的细节浮出水面

baseline 的热点图中只有 bench_baseline 一个有效符号。optimized 中，ld-2.17.so 的动态链接器符号（do_lookup_x、dl_main）、内核缺页处理链（clear_page_c → __do_page_fault → get_page_from_freelist）全部暴露出来。当用户代码不再"压过一切"时，系统基础设施的代价就变得可见了。

规律 4：样本下降倍数 ≈ 性能提升倍数

cycles:upp：834 → 208，样本数降为 25%（与运行时间 1/5 基本一致）
cpu-clock：820 → 169，样本数降为 21%

样本数不是随机下降的——它直接反映了CPU 确实花了更少的时间在这段代码上。如果两个版本样本数差不多，那说明优化根本没生效（或者瓶颈不在被优化的那段代码上）。

一句话总结：

四份 perf report 数据交叉验证了同一个故事：cache miss 是 baseline 的绝对瓶颈（98.36% Self），优化消除了 cache miss 后，用户代码 Self 降到 90%，固定开销（零初始化、动态链接、内核缺页处理）浮出水面。有无 PMU 不影响定性结论，但 cycles:upp 给出的是精确的上限数字，cpu-clock 给出的是保守的下限。

层4 回答了什么：bench_baseline 热在 +0x63 这条指令（stride=4096 的 ++row），因为每次写入都触发 cache miss，CPU 几乎把所有周期都花在了等内存上。但是——这到底是因为硬件带宽不够，还是纯粹因为 cache miss 太多？ 如果硬件带宽本来就只有 10 GB/s，那优化布局也没用。所以要回答"是硬件跟不上还是代码没写对"，需要用 perf bench 测出这台机器的理论上限。

5.5 第五层：perf bench——离硬件天花板还有多远？

层4（perf diff）告诉我们热点从 bench_baseline 转移到了 bench_optimized，固定开销占比上升。但这到底是因为硬件带宽不够，还是纯粹因为 cache miss 太多？ 如果硬件带宽本来就只有 10 GB/s，那优化布局也没用。perf bench 测出系统理论上限，排除"硬件不行"这个假设。

5.5.1 数据

bash

=== perf bench 系统微基准 ===
测试时间: 2026-08-06 10:46:33

── memcpy 带宽 ──
# Running 'mem/memcpy' benchmark:
# function 'default' (Default memcpy() provided by glibc)
# Copying 1MB bytes ...

      6.300403 GB/sec

# function 'x86-64-unrolled' (unrolled memcpy() in arch/x86/lib/memcpy_64.S)
# Copying 1MB bytes ...

      7.128193 GB/sec

# function 'x86-64-movsq' (movsq-based memcpy() in arch/x86/lib/memcpy_64.S)
# Copying 1MB bytes ...

      16.551907 GB/sec

# function 'x86-64-movsb' (movsb-based memcpy() in arch/x86/lib/memcpy_64.S)
# Copying 1MB bytes ...

      14.575560 GB/sec

── sched pipe ──
# Running 'sched/pipe' benchmark:
# Executed 1000000 pipe operations between two processes

    Total time: 6.436 [sec]

    6.436532 usecs/op
      155363 ops/sec

── sched messaging ──
# Running 'sched/messaging' benchmark:
# 20 sender and receiver processes per group
# 10 groups == 400 processes run

    Total time: 0.081 [sec]

5.5.2 表头与数据解读

perf bench 是什么？

perf bench 是 Linux perf 工具自带的微基准测试套件，它用高度优化的内联汇编实现标准操作（memcpy、memset、调度、消息传递等），测出的是当前硬件 + 当前内核版本的理论性能上限。它不是"随便写的 benchmark"，而是内核开发者用来验证硬件性能基线的工具。

memcpy 带宽——内存子系统的理论上限

实现方式	带宽	说明
glibc default	6.30 GB/s	通用 C 实现，兼容性最好
x86-64-unrolled	7.13 GB/s	手写的 x86-64 汇编，循环展开
x86-64-movsq	16.55 GB/s	用 `movsq`（串传送指令），适合大块内存
x86-64-movsb	14.58 GB/s	用 `movsb`（字节串传送），适合小块内存

为什么同一个操作有 4 种实现？ 因为不同场景（大块 vs 小块、对齐 vs 不对齐、缓存热 vs 缓存冷）下最优实现不同。glibc 的 memcpy 会根据运行时条件自动选择最优实现，但 perf bench 把它们拆开测，让你看到每种实现的天花板。

memcpy 带宽与应用吞吐的关系：

本实验每次访问 4 字节 int，按最高带宽 16.55 GB/s 计算：

bash

理论最大吞吐 = 16.55 GB/s ÷ 4 bytes/访问 = 4.14 × 10^9 次访问/秒 = 41.4 亿次/秒

实际应用吞吐（优化版）：1.143 亿次/s。理论上限 / 实际吞吐 = 41.4 亿 / 1.143 亿 ≈ 36x。

这意味着：内存带宽不是瓶颈——如果程序能充分利用 cache（L1 hit ~1ns），吞吐应该接近 41 亿次/s。当前 1.143 亿次/s 说明还有 36 倍的优化空间，但这些空间不在"内存带宽"，而在：

指令级并行：当前循环每次只做一个 ++，没有 SIMD 向量化
预取效率：虽然 stride=1 让 L1 命中率很高，但硬件预取器可能没完全饱和
编译器优化：-O2 可能还有循环展开、寄存器分配等提升空间

对比无 PMU 环境的数据（37.56 GB/s）：那台机器的 memcpy 带宽更高（可能是更新的 CPU 或不同的内存通道配置），但定性结论一致——应用吞吐远低于硬件上限，瓶颈在 cache miss 模式而非带宽。

sched pipe——进程间通信开销

指标	数值	含义
总时间	6.436 秒	100 万次 pipe 操作
单次耗时	6.437 μs	一次 `write` + `read` 的往返
吞吐	155,363 ops/sec	每秒约 15.5 万次 pipe 操作

这个数据与本实验无直接关系（本实验是单进程内存计算），但它提供了系统调度开销的基准：一次 pipe 操作 6.4 μs，相当于约 16,000 个 CPU 周期（2.5 GHz）。如果未来要把矩阵计算拆成多进程并行，pipe 通信的 overhead 就是这个量级。

sched messaging——大规模进程调度

400 个进程（20 sender + 20 receiver × 10 组）在 0.081 秒内完成消息传递。这个数据说明当前内核的调度器在短生命周期进程场景下效率很高——如果本实验未来扩展到多线程/多进程模型，调度 overhead 不会是瓶颈。

5.5.3 一句话总结

perf bench 的数据排除了"硬件带宽不够"的假设：memcpy 最高 16.55 GB/s，对应理论吞吐 41.4 亿次/s，是实际应用（1.143 亿次/s）的 36 倍。瓶颈不在内存带宽，而在软件层面的 cache miss 模式和指令级并行。五层数据从宏观到微观、从现象到根因，形成了完整的证据链。接下来 §6 将把五层数据串联起来做交叉验证。

6. 实验分析

6.1 五层数据交叉验证

把 §5 的五层数据串在一起，形成一条从"发现问题"到"定位根因"的完整证据链：

层	问题	数据	结论
层1 吞吐量	快了多少？	11.7x 加速，0.202s → 0.039s	布局差异造成了数量级的性能差距
层2 perf stat	多花了多少 CPU 周期？	cycles 6.25x ↓，L1 miss 率 52.30% → 6.40%	cache miss 是根因：IPC 从 0.18 升到 1.21
层3 perf diff	热点从哪转移到哪？	`bench_baseline` 消失，`bench_optimized` 占 90.73%	用户代码热点转移，固定开销被动上升
层4 perf report	为什么热？哪条指令？	基线版 `bench_baseline` 独占 98.73% Self	cache miss 支配一切：CPU 在等内存，不是在算
层5 perf bench	硬件跟得上吗？	memcpy 最高 16.55 GB/s → 理论上限 41.4 亿次/s	硬件不是瓶颈，软件 cache miss 模式才是

各层之间的相互印证：

层2→层4：层2说"L1 miss 率 52.30%"，层4揭示了为什么——bench_baseline 的 +0x63 指令（stride=4096 的 ++row）独占 98.73% Self，每次 load 都触发 cache miss
层4→层3：层4说"bench_baseline 消失、bench_optimized 占 90.73%"，层3验证了热点转移方向——固定开销（memset、ld.so）占比被动上升
层3→层5：层3说"固定开销成为新瓶颈"，层5排除了硬件限制——memcpy 最高 16.55 GB/s，理论吞吐 41.4 亿次/s，是实际 1.14 亿次/s 的 36 倍，瓶颈在 cache miss 模式而非带宽
层2→层5：层2中 LLC miss 从 1377 万降到 775（17,770 倍），配合层5的系统基准，说明 new int[TOTAL]() 分配 16MB 内存触发 4096 次缺页异常，每次都要内核清零一个 4KB 物理页——这是下一轮优化的起点

6.2 Amdahl 定律的量化验证

Amdahl 定律告诉我们：$S = \frac{1}{(1 - p) + p/s}$，其中 $p$ 是可优化部分的占比，$s$ 是加速比。当 $p$ 接近 1 时收益巨大（本实验 $p \approx 0.98$，$s \approx 7.85x$）；但当 $p$ 被优化到很小后，$(1-p)$ 的固定部分就成了新的天花板。

本实验用五层数据精确量化了 Amdahl 定律的两个阶段：

阶段	$(1-p)$ 固定开销	主要组成	数据来源
baseline（优化前）	~2%	`__memset_sse2`（零初始化 16MB）	层4 cycles:upp
optimized（优化后）	~10%	`__memset_sse2` 6.78% + ld.so 符号解析 ~2.3%	层4 cycles:upp

baseline 时 $(1-p)=2%$ 微不足道，optimized 时涨到 10%——不是因为固定开销变慢了，而是因为 $(1-p) / ( (1-p) + p/s )$ 中分母缩小了 6.25 倍（cycles 比值，见 §5.2.2）。层2 的 perf stat 数据精确量化了这个效应：基线版 bench_baseline 消耗 6.93 亿周期（98.73% × 7.02 亿），优化版 bench_optimized 消耗 1.03 亿周期（90.18% × 1.14 亿，取 perf stat 数据）——用户遍历逻辑快了 6.7 倍，但 __memset_sse2 的绝对周期几乎不变（~4500 万），占比从 6.41% 被动放大。

如果你继续优化到第二轮、第三轮（例如用 mmap 替代 new、预分配内存池消除缺页），固定开销 $(1-p)$ 会越来越突出——最终你会在 perf report 中看到内核缺页处理链（clear_page_c → __do_page_fault → get_page_from_freelist）成为绝对的第一大热点。这正是无 PMU 环境中优化版已呈现的趋势（clear_page_c 占 10.65%）。

6.3 PMU vs 无 PMU：如何根据环境选择方法

本实验同时留下了两种环境的数据，不是为了"凑数"，而是为了回答一个现实问题：大多数开发者都在虚拟机上干活，拿不到 PMU，怎么办？

维度	PMU 物理机（cycles:u）	无 PMU 虚拟机（cpu-clock）
采样精度	基于 CPU 周期，不受调度干扰	基于挂钟时间，被内核/调度稀释
baseline Self 占比	98.73%（真实值）	~88% 拆分为 4 条指令（保守下限）
能否看到内核热点	不能（cycles:u = user only）	能（clear_page_c 清晰可见）
适用场景	定量分析：精确量化某个瓶颈的占比	定性分析：确认热点方向、发现趋势
环境要求	物理机 / PMU 透传容器	任何 Linux 环境

方法论：

在虚拟机上先跑 cpu-clock：拿到定性趋势（哪个方向是热点、优化方向对不对），这阶段不需要 PMU
有 PMU 时用 cycles:u 验证：拿到精确占比，确认瓶颈的真实严重程度（98.73% vs 65% 差距巨大）
优化后用 perf diff 追踪变化：无论哪种事件，Delta Abs 的符号（正/负）方向一致，可以跨环境复用

6.4 一句话总结

五层递进分析形成闭环：吞吐量告诉我们"慢"（层1）→ perf stat 告诉我们"多花了多少周期、cache miss 率多少"（层2）→ perf diff 告诉我们"热点从哪转移到哪"（层3）→ perf report 告诉我们"为什么慢、哪条指令慢"（层4）→ perf bench 告诉我们"是硬件限制还是代码问题"（层5）。cache miss 是各层数据共同指向的根因，Amdahl 定律在优化后把固定开销推上了新的热点榜。

7. 实验结论

问题	答案	对应数据层
改变布局能快多少？	吞吐 11.7x，运行时间缩短至 1/5	层1
多花了多少 CPU 周期？	cycles 6.25x ↓，L1 miss 率 52.30% → 6.40%，IPC 0.18 → 1.21	层2
热点从哪转移到哪？	`bench_baseline` 消失，`bench_optimized` 占 90.73%，固定开销被动上升	层3
为什么这个函数这么热？	stride=4096 的 `++row` 指令每次都 cache miss，CPU 几乎所有周期在等内存（`cycles:u` Self=98.73%）	层4
是硬件限制还是代码问题？	memcpy 最高 16.55 GB/s，理论上限 41.4 亿次/s，远超应用的 1.14 亿次/s——瓶颈在 cache miss 模式，不在硬件带宽	层5

8. 回答开头提出的问题

数据布局能差多少？ 11.7 倍吞吐差距。同样的代码逻辑，仅仅改变了 matrix[row * COLS + col] 到 matrix[col * ROWS + row]，就是 10 倍以上的性能鸿沟。根源是 stride-4096 的访问模式每步都触发 cache miss（层4）。
perf stat 怎么用？ 它是"硬件计数器"——直接读出 cycles、cache-misses、L1-dcache-load-misses、LLC-load-misses 等 8 个 PMU 事件，精确量化"多花了多少周期、cache miss 率多少、IPC 多少"。本实验中 cycles 6.25x ↓、L1 miss 率 52.30% → 6.40%、IPC 0.18 → 1.21，三条数据互相印证（层2 §5.1.2）。
perf diff 怎么用？ 它是"优化账单"——告诉你哪些函数的热度在下降（优化有效），哪些在上升（新瓶颈）。关键认知：Delta Abs 是占比差，不是绝对值差（层3 §5.2.1）。结合 perf stat 硬件计数（层2）、perf diff 热点转移（层3）、perf report 指令拆解（层4）和 bench 理论上限对照（层5），四者联动形成"宏观-硬件计数-热点转移-指令根因-硬件上限"的五层分析闭环。
能把用户代码优化到极致吗？ 问题不在于能不能快，而在于快起来之后谁成为新的瓶颈。本实验中，优化后 __memset_sse2 占比从 6.41% 被动放大，内核缺页处理链（clear_page_c + __do_page_fault + get_page_from_freelist）在无 PMU 环境中总计超过 20%。下一轮优化目标就是 new int[TOTAL]() 触发的缺页分配（层4→层5）。
有 PMU 和无 PMU 的数据差异说明了什么？ cpu-clock 的 baseline Self 仅 ~65%，而 cycles:u 高达 98.73%——差距来自采样机制：一个基于时间（被调度稀释），一个基于 CPU 周期（精确）。日常在虚拟机上有 40~60% 的热点占比别以为"优化空间还很大"，物理机上可能已经 90%+ 了（§6.3）。

关联文档

tools/code/perf.md —— perf 工具主文档，§六.4 perf diff、§六.5 组合速查
concepts/tools/perf-demos-architecture.md —— perf 12 场景学习架构总纲
concepts/elf/symbol-table.md —— 符号表深度剖析（perf diff 如何解析符号地址）

一句话：perf stat 用硬件计数器直接读出 cycles、cache-misses、L1-dcache-load-misses 等 9 个事件，精确量化瓶颈；perf diff 把"优化有用吗？"变成精确的数字——每个函数的 Delta% 揭示开销的去向；perf bench 提供机器的理论上限，perf report 拆解热点后你可以看到 Amdahl 定律在真实场景中的体现。

CPU 微架构总纲

内存序总纲

CPU 硬件架构总纲

缓存与内存

一致性协议对比

进程总纲

进程数据结构(task_struct)

VFS总纲

ELF 总纲

NUMA 总纲

网络总纲

内核调用链（socket → bind → listen → accept）

IO 模型与并发

传输控制

内核调优与硬件

I/O 总纲

PCIe 主题

低延时设计

容器技术

存储系统

perf 工具指南

高级性能工具

perf实战案例集

调试与调优

CPU 指标

内存指标

IO 指标

网络指标

调度指标

CPU性能演示(cpu_demo)

TLB抖动演示

动态探针演示(D11)

阶段1 写出Echo

Day 1: TCP Echo 从零

Day 2: 本地测试

阶段2 FD瓶颈

Day 4: FD 限制

Day 5: FD 与 ulimit

Day 6: 修复 FD 验证 10K

阶段3 TCP参数

阶段4 CPU/软中断

阶段5 NUMA深入

阶段6 百万连接

阶段7 短连接

阶段8 进阶复盘

perf-bench-diff —— 微基准测试与优化前后对比实验 ​

0. 术语速查 ​

1. 本实验要回答的问题 ​

2. 实验设计 ​

2.1 被测程序 ​

2.1.1 两种存储布局 vs 遍历方向的可视化 ​

2.2 实验流程 ​

2.2.1 一键命令 ​

2.2.2 各步骤作用 ​

2.3 实验环境 ​

3. 代码设计 ​

3.1 类图 ​

3.2 数据布局：两个 Matrix 结构体 ​

3.3 基准函数：两个 bench 函数 ​

4. 实验预期 ​

5. 实验数据 ​

5.1 第一层：吞吐量——宏观上快了多少？ ​

5.1.1 PMU 环境补充：5 轮平均吞吐量 ​

5.1.2 PMU 环境：perf stat 硬件计数器全景 ​

5.1.2.1 事件选择 ​

5.1.2.2 原始 perf stat 输出 ​

5.1.2.3 perf stat 各指标逐项分析 ​

5.1.2.4 perf stat 指标关联全景 ​

5.1.2.5 perf stat 小结论 ​

5.2 第三层：perf diff——热点从哪个函数转移到了哪里？ ​

5.2.1 看懂 perf diff 的表头 ​

5.2.2 数据与逐行分析 ​

5.2.3 一句话总结 ​

5.3 第四层：perf report——函数内部哪条指令最热？ ​

5.3.1 perf report 表头说明 ​

5.3.2 基线版——有 PMU 环境（cycles:upp 事件，834 样本） ​

5.3.3 基线版——无 PMU 环境（cpu-clock 事件，820 样本） ​

5.3.4 优化版——有 PMU 环境（cycles:upp 事件，208 样本） ​

5.3.5 优化版——无 PMU 环境（cpu-clock 事件，169 样本） ​

5.3.6 四份数据的全景对比 ​

perf-bench-diff —— 微基准测试与优化前后对比实验

0. 术语速查

1. 本实验要回答的问题

2. 实验设计

2.1 被测程序

2.1.1 两种存储布局 vs 遍历方向的可视化

2.2 实验流程

2.2.1 一键命令

2.2.2 各步骤作用

2.3 实验环境

3. 代码设计

3.1 类图

3.2 数据布局：两个 Matrix 结构体

3.3 基准函数：两个 bench 函数

4. 实验预期

5. 实验数据

5.1 第一层：吞吐量——宏观上快了多少？

5.1.1 PMU 环境补充：5 轮平均吞吐量

5.1.2 PMU 环境：perf stat 硬件计数器全景

5.1.2.1 事件选择

5.1.2.2 原始 perf stat 输出

5.1.2.3 perf stat 各指标逐项分析

5.1.2.4 perf stat 指标关联全景

5.1.2.5 perf stat 小结论

5.2 第三层：perf diff——热点从哪个函数转移到了哪里？

5.2.1 看懂 perf diff 的表头

5.2.2 数据与逐行分析

5.2.3 一句话总结

5.3 第四层：perf report——函数内部哪条指令最热？

5.3.1 perf report 表头说明

5.3.2 基线版——有 PMU 环境（`cycles:upp` 事件，834 样本）

5.3.3 基线版——无 PMU 环境（`cpu-clock` 事件，820 样本）

5.3.4 优化版——有 PMU 环境（`cycles:upp` 事件，208 样本）

5.3.5 优化版——无 PMU 环境（`cpu-clock` 事件，169 样本）

5.3.6 四份数据的全景对比

5.5 第五层：perf bench——离硬件天花板还有多远？

5.5.1 数据

5.5.2 表头与数据解读

5.5.3 一句话总结

6. 实验分析

6.1 五层数据交叉验证

6.2 Amdahl 定律的量化验证

6.3 PMU vs 无 PMU：如何根据环境选择方法

6.4 一句话总结

7. 实验结论

8. 回答开头提出的问题

关联文档