各位同学，大家早上好。很高兴今天能站在这里。
我知道你们很多人，可能每天都在写代码。写 Python？写 Java？写 JavaScript？或者是为了性能勉强搬砖的 C++？你们都觉得自己挺厉害，因为你们懂闭包，懂虚函数，懂垃圾回收（GC）。
但是，今天我要告诉你们一个残酷的事实：在 CPU 那个只有 0 和 1 的世界里，你们写的高级语言，不过是写给人类看的“天书”，而 CPU 只能听懂“二进制咒语”。
所谓的 JIT（Just-In-Time）编译器，说白了就是一个贪心的翻译官。它在程序运行的那一瞬间，把你们的 Python 代码、Java 代码，或者 JavaScript 代码，翻译成了一坨看起来很美的机器码。
今天，我们要做的就是剥开这坨机器码的外衣，看看里面到底藏着什么。我们要用 perf 工具，这只系统级的大白鲨，去嗅探那些导致性能毛刺的罪魁祸首。
准备好了吗？让我们把 CPU 的风扇调大一点，开始吧。
第一部分：你以为的“慢”，其实是 CPU 在“假死”
首先，我们要纠正一个普遍的误解：当你觉得你的程序慢的时候，你通常不会去想 CPU。你会想：“哎呀，是不是我的算法太烂了？”或者“是不是内存不够了？”
其实，当你打开任务管理器，看着 CPU 占用率飙到 90% 的时候，你以为 CPU 忙疯了。其实，CPU 可能正躺在沙发上喝着可乐，冷冷地看着你的程序说：“这代码写得真烂，我每执行一条指令都要停下来思考半天，太累了。”
CPU 的运行速度是以纳秒（ns）计算的，而内存的访问延迟是以时钟周期（Cycle）计算的。 这两者的差距，就是你们性能毛刺的温床。
JIT 编译器生成的汇编代码，是离 CPU 最近的。如果 JIT 编译出来的机器码写得像一盘散沙，CPU 的流水线就会被打断。这就好比你在流水线上工作，老板刚喊了一声“干活！”，你就突然想：“哎呀，这根螺丝拧哪里来着？”——停顿 10 个周期，整条生产线就瘫痪了。
这时候，perf 工具就出场了。它不是让你看代码行数，它是让你看时钟周期。
第二部分：Perf 的魔法——不只是统计，是读心术
很多同学问：“怎么用 perf？”
我说：“别问怎么用，直接用。就像用杀毒软件一样，不要犹豫。”
最基本的命令：
perf stat -e cycles,instructions,cache-misses ./my_jit_program这个命令是什么意思？
cycles: CPU 完成指令所需的时钟周期总数。这是上帝的时钟，最客观的衡量标准。instructions: CPU 执行的指令总数。cache-misses: 缓存未命中次数。这是 CPU 摸不到内存时发出的惨叫声。
运行完，你会看到一堆数字。如果 IPC (Instructions Per Cycle) 小于 1，恭喜你，你的程序在“浪费”时间。如果 cache-misses 很高，那你的程序就是典型的“内存饥民”。
但是，光看数字不够。数字是死的，CPU 的状态是活的。我们需要记录。
perf record -g -p $(pgrep my_jit_program) -- sleep 10
perf report这里加了 -g，这可是个宝贝。它会记录调用栈。在汇编层面，perf 会告诉你，是哪一行机器码让你挂了。
第三部分：热点分析——机器码层面的“战火”
好，假设你的 JIT 编译器是个笨蛋，它生成了一堆很难看的代码。我们来看看怎么找出这些代码。
场景 1：未对齐的内存访问
假设你在 C 语言里写了一个简单的数组累加：
void add_array(int* arr, int size) {
for (int i = 0; i < size; i++) {
arr[i] += 1;
}
}如果你没有显式地对齐内存，或者 JIT 翻译的时候偷懒了，那么这个循环在汇编层面可能会变成这样（伪代码）：
L1:
mov eax, [rdi] ; 读取数据
add eax, 1 ; 加法
mov [rdi], eax ; 写回数据
add rdi, 4 ; 指针移动 4 字节
dec rcx ; 计数器减 1
jnz L1 ; 如果没完，跳回去这看起来很正常，对吧？但这有个大问题：数据对齐。
如果数组不是 64 字节对齐的，当你执行 add rdi, 4 的时候，CPU 可能需要同时访问 L1 缓存的两个不同行。这会导致 L1 缓存行（通常 64 字节）被分割，或者更糟，触发一次缓存未命中。
这时候，你用 perf 一看：
$ perf stat -e cache-references,cache-misses ./program
Performance counter stats for './program':
1,234,567,890 cache-references
45,678,901 cache-misses # 3.70% of all cache refs这 3.7% 的 cache miss，意味着 CPU 有 3.7% 的时间在傻傻地等待内存把数据送过来，而不是在疯狂计算。这就是性能毛刺。
JIT 编译器的任务： 它应该在生成代码的时候，检查对齐，或者插入 prefetch 指令（预取指令），提前把下一块数据从内存搬到缓存里。
场景 2：糟糕的分支预测
CPU 的分支预测器是个天才，但也是个瞎子。它通过历史记录猜测你会走哪个分支。如果你写的代码模式是随机的，预测器就废了。
比如，你有一个循环判断：
for (int i = 0; i < 1000000; i++) {
if (some_random_function(i) > 0) {
// do something
}
}在汇编层面，这会变成：
L2:
call some_random_function
test eax, eax
jg L3 ; 如果大于0，跳转到 L3
jmp L2
L3:
; do something
jmp L2如果 some_random_function 返回的值完全随机，CPU 的预测器会频繁犯错。每一次预测错误，都会导致流水线清空，CPU 停止工作几个周期。
这时候，perf 会给你看一个悲伤的指标：branch-misses。
$ perf stat -e branches,branch-misses ./program
Performance counter stats for './program':
1,000,000 branches
500,000 branch-misses # 50.00% of all branches哇，一半的分支都预测错了！这就是为什么你的游戏帧率从 60 跳到了 5。
JIT 编译器的任务： 优化条件跳转。比如，把 if (i % 2 == 0) 这种操作，直接用位运算 if (i & 1)，或者如果是连续的值，直接展开循环，让 CPU 没有机会看到 if。
第四部分：实战演练——手把手教你抓“鬼”
现在，我们假设你正在开发一个基于 PyPy 的 Python 程序。你写了这段代码：
import random
def simulate(data):
total = 0
for item in data:
if random.random() > 0.5:
total += item
else:
total -= item
return total你觉得这代码很简单，跑起来应该飞快。但是，你发现数据量大的时候，它突然卡顿了一下。
第一步：生成热点报告
运行：
perf record -g ./simulate.py -- data_file.txt
perf report --stdio | less你会看到 simulate 函数占据了 80% 的 CPU 时间。点进去，你会看到红色的区域指向 random.random()。
第二步：深入汇编
好，问题出在随机数生成器。但是，为什么随机数生成器会导致 CPU 瓶颈？
perf annotate 可以帮你看。
perf annotate simulate.py你会看到 random 函数内部有一大段汇编代码，充满了 mov 和 xor。这其实不是最关键的，关键在于它频繁访问全局变量。
假设 JIT 生成的代码是这样的（简化的 x86-64）：
# 假设 JIT 生成的代码片段
get_seed:
mov rax, [rip + __seed] ; 从全局变量读种子，可能涉及 L1 缓存
imul rax, 1103515245
add rax, 12345
mov [rip + __seed], rax ; 写回种子
ret
simulate_loop:
mov rdi, item_ptr ; 加载当前 item
mov rax, 1
mov rsi, 2147483648
mul rsi # 乘以随机数
cmp rax, 0x7FFFFFFF # 比较
ja take_branch_yes ; 超出范围，跳转
jmp take_branch_no
take_branch_yes:
add rdx, [rdi] # 加法指令
jmp next_item
take_branch_no:
sub rdx, [rdi] # 减法指令
jmp next_item这里有个巨大的隐患：mul 指令。
在 x86 架构中，mul（无符号乘法）是串行执行的。这意味着，如果流水线里有其他指令在跑，mul 指令必须等待前一个周期算完才能开始。而且，mul 需要消耗 3 个时钟周期（通常情况）。
如果我们的循环体很小，前面是加载 item，后面是 add，那么 mul 就会卡在中间，导致 CPU 的其他单元（比如 ALU，算术逻辑单元）处于闲置状态。这就是为什么 IPC 会很低。
这时候，我们该怎么办？优化？
第三步：JIT 优化策略
作为开发者，我们要让 JIT（或者我们手动优化这段 C 代码）做以下几件事：
- 减少除法/乘法：
mul指令是瓶颈。我们可以利用位操作来近似随机数，或者预计算一些值。 - 循环展开：不要每次都调用
random。在 JIT 里，我们可以尝试展开循环，把随机数预加载好，减少调用random的开销，也减少分支预测的压力。
假设优化后的代码变成了：
simulate_loop_optimized:
# 假设我们把循环展开了，一次处理两个 item
mov rdi, [rsi] # item 1
mov rbx, [rsi+8] # item 2
mov rax, 1
mul rsi # 随机数 1
add rdx, rdi # 直接加，或者判断
mul rsi # 随机数 2
add rdx, rbx
add rsi, 16 # 指针移动 16 字节
dec rcx
jnz simulate_loop_optimized注意，虽然 mul 还在，但是循环展开减少了分支跳转，并且提高了内存访问的局部性（一次取 16 字节）。
再次用 perf 运行：
perf stat -e cycles,instructions,cache-misses ./optimized_program你会发现 cache-misses 降下来了，branches 也降下来了，虽然 cycles 可能没变（因为乘法还是很慢），但整体 IPC 可能会上升。
第五部分：不仅仅是 CPU——TLB 和 Cache Line
有时候，性能毛刺不是因为 CPU 算得慢，而是因为 CPU 想找数据找不到。
这里涉及到两个概念：TLB（Translation Lookaside Buffer，页表缓冲） 和 Cache Line（缓存行）。
TLB 悲剧
当你访问一个数组元素 arr[i] 时，CPU 先查 TLB。如果 TLB 里没有这个地址（比如你访问了一个非常大的数组，跨越了 4KB 页面），CPU 就得去查页表，这需要几十到几百个时钟周期。
如果你在 JIT 里写了一个死循环，一直在访问同一块内存，TLB 会命中。但如果你做了指针跳转，或者迭代步长很大，TLB 就会失效。
Cache Line 竞争
这是多核编程中最恶心的事情。如果两个 CPU 核心同时修改数组中相邻的两个元素，而这个数组恰好在同一个 64 字节的 Cache Line 里，那么缓存一致性协议（MESI）就会疯狂报警。
A 核心写了数据，缓存行标记为“脏”，然后通知 B 核心。B 核心正在读这个数据，收到通知后，必须把旧数据从 L2 缓存里扔掉，重新从 A 核心那里拉过来。
这就叫 False Sharing（假共享）。
在汇编层面，这表现为极高的 L1d-loads-misses 或者 LLC-loads-misses。
如何用 Perf 发现它？
perf top -e cache-references,cache-misses如果看到某个特定的地址频繁出现在热点列表中，那就小心了。
JIT 的修复方案： 强制填充（Padding）。在结构体之间加入 char padding[64]，确保两个核心不会触碰同一个缓存行。
第六部分：图表与火焰图——可视化你的混乱
光看数字太枯燥了，像个老会计。我们需要火焰图。
火焰图是 Linux 世界里最美丽的魔法。
- 运行
perf record -g -F 99 --sleep 5 ./program-F 99：采样频率，每 99 个时钟周期抓拍一次，非常精准。
- 运行
perf flamegraph（或者flamegraph.pl脚本）。 - 你会看到一个巨大的树状图。
在这个图上，x 轴代表样本数（时间），y 轴代表调用栈的深度。
如果火焰图显示了一个巨大的宽块，那说明这就是你的热点。
如果火焰图里充满了像梵高画一样的锯齿状（每个分支都一样宽），这说明你的程序是随机访问的，CPU 分支预测器正在绝望地呐喊。
在这个图上，你还能看到汇编代码吗？可以。
使用 perf report --stdio，加上 objdump 的参数。
perf report --stdio -g --no-symfs --no-kernel -C my_program这会打印出汇编代码，甚至带上源码行号（如果符号表齐全）。
第七部分：高级技巧——反汇编 JIT 代码
这可是个高阶玩法。JIT 生成的代码通常是动态分配的，地址是乱七八糟的。
假设你的 Node.js 程序慢了。你可以用 perf record 录下 trace。
然后，找到对应的二进制文件，用 objdump -d 反汇编。
objdump 会显示一堆乱码地址，比如 0x0000000000401a00。
你可以用 perf script 找到这些地址对应的时间。
perf script | grep 0x0000000000401a00或者，更简单的方法，直接用 perf annotate 指向你的可执行文件，然后手动跳转到那个地址。
甚至，如果你有符号表，你可以把 JIT 生成的内存 dump 出来，保存为 jit_code.s，然后用 objdump -d jit_code.s > jit_code.asm。这时候，你就能看到 JIT 到底给你翻译了什么狗屎代码。
比如，你可能看到 JIT 忘记内联一个简单的 memcpy，而是生成了一堆 movsb 指令在循环里搬运。这就是性能杀手。
总结与思考
好了，各位。
我们聊了很多，从 cycles 到 cache-misses，从 branch-misses 到 TLB。我们要明白一个道理：现代 CPU 的设计极其复杂，但性能瓶颈往往很简单。
很多时候，性能毛刺不是因为你写了复杂的算法，而是因为：
- 数据没对齐（导致缓存行撕裂）。
- 分支预测失败（导致流水线清空）。
- 缓存未命中（导致 CPU 在等内存）。
- 指令集选择错误（用了慢速的串行指令，比如
mul）。
JIT 编译器就像一个匆忙的工匠。它有极短的时间来“编译”你的代码（因为程序必须在运行中编译），它没有时间去仔细打磨每一行汇编。它可能会为了减少代码体积而牺牲执行速度，或者为了减少内存占用而使用低效的寻址模式。
作为开发者，我们不能只盯着“源代码”看。我们要学会拿起 perf 这把手术刀，切开 CPU 的外壳，看看里面的齿轮是如何咬合的。
下次当你觉得代码慢的时候，不要猜。运行 perf stat，看 IPC，看缓存，看分支。让数据告诉你真相。
CPU 在等着你优化它的流水线，别让它失望。
谢谢大家。