CPU 微架构与 TLB/Cache

#系统 · #进阶 · #CPU · #Cache · #TLB · #流水线 · #乱序执行

深入处理器微架构，理解指令流水线、Cache 和 TLB 的工作原理，多平台对比，优化实战。

1. 处理器微架构基础

1.1 指令执行的基本流程

每条指令经过 取指(Fetch) → 译码(Decode) → 执行(Execute) → 访存(Memory) → 写回(Writeback) 五个阶段。

1.2 流水线的演变

顺序单周期 → 顺序流水线 → 乱序超标量 → 推测执行

Intel 微架构演进：

架构	代表产品	关键特性
P5	Pentium (1993)	首个超标量 x86（2发射）
P6	Pentium Pro → Core 2	乱序执行、μop 解码
NetBurst	Pentium 4	超长流水线（31级），后因功耗过高被放弃
Core	Conroe → Sandy Bridge	回归短流水线 + 高效
Skylake	6~10代 Core	4发射、深度缓冲
Golden Cove	12代 Core (P-core)	6发射、更大 ROB
Zen 4	AMD Ryzen 7000	AVX-512、改进分支预测

1.3 μop（微操作）架构

现代 x86 将复杂 CISC 指令解码为类 RISC 的 μop：

x86 add [mem], reg
→ μop1: load [mem] → tmp
→ μop2: tmp + reg → result
→ μop3: store result → [mem]

2. 指令集架构对比（ISA）

2.1 RISC vs CISC

mermaid

graph TD
    subgraph CISC["CISC - 复杂指令集"]
        C1["x86/x86-64 (Intel/AMD)"]
        C2["指令长度可变 1~15B"]
        C3["一条指令可做多件事"]
        C4["微码解码为 μop"]
    end
    subgraph RISC["RISC - 精简指令集"]
        R1["ARM/AArch64, RISC-V, MIPS, PowerPC"]
        R2["指令定长 (ARM 4B, RISC-V 4B/2B)"]
        R3["一条指令做一件事"]
        R4["Load/Store 架构"]
    end

维度	CISC (x86-64)	RISC (ARM64)	RISC-V
指令长度	1~15 字节变长	固定 4 字节	固定 4B (压缩 2B)
寄存器数	16 通用(GPR)	31 GPR	31 GPR
寻址方式	复杂(内存+运算一条指令)	Load/Store 分离	Load/Store 分离
条件码	隐式 FLAGS 寄存器	显式条件选择	显式比较+分支
典型实现	μop 解码+乱序	宽发射+乱序	简洁设计
代表厂商	Intel, AMD	Apple, Qualcomm, 华为	开源, 各厂商

同一操作对比：

asm

# 内存加法: A[i] += b

# x86-64 (CISC): 一条指令搞定
addq    %rbx, (%rax,%rcx,8)

# ARM64 (RISC): 三条指令
ldr     x0, [x1, x2, lsl #3]   # load A[i]
add     x0, x0, x3              # add b
str     x0, [x1, x2, lsl #3]   # store back

2.2 多平台架构对比

Intel/AMD x86-64

参数	Intel Golden Cove (12代 P-core)	AMD Zen 4 (Ryzen 7000)
发射宽度	6 指令/周期	6 指令/周期 (双3)
ROB 大小	~512 条目	320 条目
L1-I Cache	32KB, 8路	32KB, 8路
L1-D Cache	48KB, 12路	32KB, 8路
L2 Cache	1.25MB (P-core独享)	1MB (独享)
L3 Cache	共享, 最大 30MB	共享, 最大 128MB (3D V-Cache)
流水线深度	~14-19级	~19级
制程	Intel 7 (10nm)	TSMC 5nm
AVX-512	yes (E-core无)	yes
大小核	yes (P-core + E-core)	no

Apple Silicon (M 系列)

参数	M1 (2020)	M2 (2022)	M3 (2023)
ISA	ARMv8.4-A	ARMv8.5-A	ARMv9-A
发射宽度	8 指令/周期	8	9
ROB	~630	~670	~700+
L1-I / L1-D	192KB / 128KB	192KB / 128KB	192KB / 128KB
制程	TSMC 5nm	5nm (增强)	3nm
统一内存	LPDDR4X-4266	LPDDR5-6400	LPDDR5-6400

Apple Silicon 优势：超宽解码(8-wide)、超大 ROB、超大 L1 Cache，单核性能极度依赖 ILP 挖掘。配合统一内存架构，CPU/GPU/NPU 共享内存池，延迟极低。

ARM 服务器 (AWS Graviton / 华为鲲鹏)

参数	AWS Graviton3	华为鲲鹏 920
核心	Neoverse V1, 64核	泰山 V110, 64核
ISA	ARMv8.4-A	ARMv8.2-A
制程	TSMC 5nm	7nm
优势	高能效、多核密度高、每瓦性能优异	自主设计微架构

RISC-V

asm

# RISC-V RV64GC 示例 — 完全开放的指令集，无授权费
addi    sp, sp, -16        # 分配栈空间
sd      ra, 8(sp)          # 保存返回地址
li      a0, 42             # 加载立即数 (伪指令)
call    printf             # 调用函数
ld      ra, 8(sp)          # 恢复返回地址
addi    sp, sp, 16         # 释放栈空间
ret

RISC-V 特点：模块化设计（RV32I 基础整数集 + M/A/F/D/C 等扩展），无历史包袱，非常适合教学和嵌入式。

2.3 CPU vs GPU vs NPU

mermaid

graph LR
    subgraph CPU
        C1["少量强核心 ~4-16核"]
        C2["大Cache, 乱序执行"]
        C3["适合: 延迟敏感<br/>(OS, 数据库, Web)"]
    end
    subgraph GPU
        G1["大量简单核心 ~数千核"]
        G2["SIMT 模型(单指令多线程)"]
        G3["适合: 吞吐量敏感<br/>(矩阵, 图形, 训练)"]
    end
    subgraph NPU
        N1["专用矩阵加速器"]
        N2["Tensor Core / Neural Engine"]
        N3["适合: 推理加速<br/>(CNN, Transformer)"]
    end

维度	CPU	GPU (NVIDIA)	Apple Neural Engine
架构	通用标量	SIMT 向量	专用矩阵乘法
核心数	4~128	数千	16 Core (ANE)
精度	FP64/FP32/INT	FP16/BF16/INT8/FP4	FP16/INT8
TOPS (推理)	~0.1-1	~100-1300	~35 (A17/M3)
延迟	低（直连）	高（需 PCIe 传输）	极低（统一内存）

// CPU vs GPU 计算对比
// CPU 版本 (标量循环)
for (int i = 0; i < N; i++)
    c[i] = a[i] + b[i];

// GPU CUDA 版本 (SIMT) — 数千线程并行
__global__ void vec_add(float *a, float *b, float *c, int N) {
    int i = blockIdx.x * blockDim.x + threadIdx.x;
    if (i < N) c[i] = a[i] + b[i];
}
// 启动: vec_add<<<num_blocks, 256>>>(a, b, c, N);

3. 指令级并行 (ILP)

3.1 超标量

处理器每个周期发射多条指令，需要多个功能单元并行工作。

┌─────────────────────────────────────────┐
│            指令调度器                     │
│  ┌─────┐  ┌─────┐  ┌─────┐  ┌─────┐   │
│  │ ALU0│  │ ALU1│  │ AGU0│  │ AGU1│ ...│
│  └─────┘  └─────┘  └─────┘  └─────┘   │
│  ┌─────┐  ┌─────┐  ┌─────┐             │
│  │ FPU0│  │ FPU1│  │ BR  │             │
│  └─────┘  └─────┘  └─────┘             │
└─────────────────────────────────────────┘

3.2 乱序执行 (Out-of-Order, OoO)

核心数据结构：

结构	作用
ROB (Reorder Buffer)	记录指令的原始顺序，保证按序提交
保留站 (Reservation Station)	等待操作数就绪的指令暂存处
物理寄存器文件	通过寄存器重命名消除 WAR/WAW 假依赖

处理器内部：取指 → 寄存器重命名 → 保留站 → 调度执行 → ROB提交

3.3 数据冒险与转发网络

指令1: add r1, r2, r3   (r1 = r2 + r3)
指令2: sub r4, r1, r5   (r4 = r1 - r5)  ← 依赖指令1的结果

如果无转发：指令2需要等指令1写回（2周期stall）
有转发：ALU结果在计算完成后直接转发给下条指令的ALU输入端

3.4 分支预测

为什么重要：现代处理器流水线很深（14~19级），分支预测错误代价 = 流水线深度 × 宽度。

常见预测器：

预测器	原理	准确率
静态预测	向后跳转→预测跳，向前→不跳	~60-70%
双模预测（Bimodal）	2位饱和计数器	~85-90%
两级自适应	全局/局部历史 + PHT	~90-95%
混合预测	多种预测器 + 选择器	~95-97%
TAGE	多长度历史表 + 几何级索引	~97-99%（现代主流）
Perceptron	神经网络预测	研究前沿

// 可预测 vs 不可预测分支的性能差异
#include <stdlib.h>
int cmp(const void *a, const void *b) { return *(int*)a - *(int*)b; }

void branch_test() {
    int N = 100000;
    int *data = malloc(N * sizeof(int));
    for (int i = 0; i < N; i++) data[i] = rand() % 256;

    // 未排序: 分支预测准确率 ~50%
    clock_t t1 = clock();
    long sum = 0;
    for (int i = 0; i < N; i++)
        if (data[i] >= 128) sum += data[i];
    clock_t t2 = clock();

    // 排序后: 分支预测准确率 ~95%+
    qsort(data, N, sizeof(int), cmp);
    sum = 0;
    clock_t t3 = clock();
    for (int i = 0; i < N; i++)
        if (data[i] >= 128) sum += data[i];
    clock_t t4 = clock();

    printf("未排序: %.2f ms, 已排序: %.2f ms\n",
           1000.0*(t2-t1)/CLOCKS_PER_SEC, 1000.0*(t4-t3)/CLOCKS_PER_SEC);
    // 排序后通常快 2-3 倍!
}

// 无分支版本 — 数据随机时远优于分支版本
int min_branchless(int a, int b) {
    int mask = (a - b) >> 31;   // a<b 时 mask=-1, 否则 0
    return (a & ~mask) | (b & mask);
}

4. 多核与多线程

4.1 多核架构

┌──────────────────────────────────────────────┐
│                  L3 Cache (共享)               │
│    ┌──────────────┐     ┌──────────────┐      │
│    │    Core 0    │     │    Core 1    │      │
│    │ ┌──┐  ┌──┐  │     │ ┌──┐  ┌──┐  │      │
│    │ │L1│  │L1│  │     │ │L1│  │L1│  │      │
│    │ │I │  │D │  │     │ │I │  │D │  │      │
│    │ └──┘  └──┘  │     │ └──┘  └──┘  │      │
│    │   L2 Cache   │     │   L2 Cache   │      │
│    └──────────────┘     └──────────────┘      │
│           互连总线 (Ring/Mesh)                  │
└──────────────────────────────────────────────┘

4.2 SMT（同时多线程，Intel 超线程）

一个物理核心维护多套架构状态（寄存器文件、PC），在同一个周期内可以执行来自不同线程的指令，提升功能单元利用率。

4.3 Cache 一致性协议：MESI

多核共享内存场景下，保证各核心 Cache 中数据的一致性。

状态	全称	含义
M	Modified	仅本核心有，已修改，与内存不一致
E	Exclusive	仅本核心有，与内存一致
S	Shared	多个核心共享，与内存一致
I	Invalid	无效（需从其他核心或内存获取）

状态转换示例：
核心A读X   → E (Exclusive)
核心B读X   → A: S, B: S (都变为Shared)
核心A写X   → A: M, B: I (A独占修改，B失效)
核心B读X   → A: S, B: S (A写回到内存，B读取)

4.4 MESI 状态转换 — 完整图解

mermaid

stateDiagram-v2
    direction LR
    [*] --> I: 初始状态

    I --> E: 本核读(RH) / 其他核都没有
    I --> S: 本核读(RH) / 其他核也有

    E --> E: 本核读
    E --> M: 本核写(WH)
    E --> S: 其他核读(总线嗅探)
    E --> I: 其他核写(总线嗅探)

    S --> S: 本核读
    S --> M: 本核写(WH) → 广播使其他核 I
    S --> I: 其他核写(总线嗅探)

    M --> M: 本核读/写
    M --> S: 其他核读(写回内存+共享)
    M --> I: 其他核写(写回内存+失效)

双核并发写的完整过程：Core0 和 Core1 同时尝试写入同一 Cache Line → 首先获得总线所有权的核心从 I→E→M 开始写，另一核心通过总线嗅探发现冲突→发送 RFO(Request For Ownership)→当前 M 状态的核心必须先写回内存再置为 I→请求方获得所有权后置为 E→M 开始写。这一来一回约 40-100ns，是 L1 Cache 命中(1ns)的 40-100 倍。

4.5 分支预测失败的性能影响量化

分支预测失败是 CPU 微架构中最昂贵的单一事件之一——它在高性能 CPU 上会"浪费"大量的指令发射槽位：

一条分支指令预测失败 = 流水线深度 × 发射宽度 条指令白做了

Intel Golden Cove (6-wide, ~14-19 级):
  → 14×6 = 84 条指令被丢弃 → 约 14-19 个周期完全浪费

Apple M1 (8-wide, ~14 级):
  → 14×8 = 112 条指令被丢弃 → 约 14 个周期

对于性能关键代码:
  误预测率 = 1%  → 相当于 0.14 个误预测/100 指令 → 约 2-3% 性能损失
  误预测率 = 10% → 相当于 1.4 个误预测/100 指令  → 约 20-30% 性能损失

// 实际性能测试: 随机 vs 排序数组
// 数组大小=256B (全在 L1 Cache 内, 消除 Cache 干扰)
//
// 排序后: 预测准确率 ~100%, 吞吐 ~4-5 cycle/iter
// 随机:   预测准确率 ~50%,  吞吐 ~14-18 cycle/iter
// 分支预测失败惩罚: ~20 个周期 (对应 Skylake 流水线深度)

x86 是强内存模型（TSO），ARM/RISC-V 是弱内存模型。

屏障	x86	ARM
全屏障	`mfence`	`dmb ish`
读屏障	`lfence`	`dmb ishld`
写屏障	`sfence`	`dmb ishst`

#include <stdatomic.h>

// x86 (TSO): Load不能重排到Store之前，只需关注Store-Load重排
// ARM/RISC-V: 所有重排都可能发生！必须显式屏障

// 跨平台安全写法: 使用 C11 原子操作
_Atomic int ready = 0; int data = 0;

void producer() {
    data = 42;
    atomic_store_explicit(&ready, 1, memory_order_release);
    // ARM: stlr (store-release), x86: 普通 mov
}

void consumer() {
    while (!atomic_load_explicit(&ready, memory_order_acquire))
        ;  // ARM: ldar (load-acquire)
    printf("%d\n", data);  // 保证看到 data = 42
}

5. TLB（Translation Lookaside Buffer）

5.1 TLB 的作用

TLB 是 MMU 内部的硬件缓存，缓存虚拟地址到物理地址的转换结果。

虚拟地址 ──→ [TLB 查找] ──命中──→ 物理地址
                 │ 缺失
                 ↓
            [页表遍历] ──→ 填充 TLB ──→ 物理地址

5.2 TLB 的组织结构

参数	Intel Skylake 示例
L1 ITLB	128 条目, 4路组相联 (4KB页) + 8条目全相联 (2MB/4MB页)
L1 DTLB	64 条目, 4路组相联 (4KB页) + 32条目全相联 (2MB/4MB页)
L2 STLB	1536 条目, 12路组相联（共享）

5.3 TLB 缺失的代价

L1 TLB 命中：~1 周期
L2 TLB 命中：~5-8 周期
页表遍历（内存访问）：~20-100 周期
处理缺页中断：数百万周期（需磁盘 I/O）

5.4 大页（Huge Pages）

页大小	TLB 覆盖范围（1536条目）
4KB	6MB
2MB	3GB
1GB	1.5TB

bash

# 查看大页信息
cat /proc/meminfo | grep Huge
# 启用透明大页（THP）
echo always > /sys/kernel/mm/transparent_hugepage/enabled

#include <sys/mman.h>
// 使用 2MB 大页分配内存 (需要内核支持 hugetlbfs)
void *huge = mmap(NULL, 2*1024*1024,
    PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0);

// 或通过 madvise 建议内核使用透明大页
void *p = mmap(NULL, size, PROT_READ|PROT_WRITE,
               MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
madvise(p, size, MADV_HUGEPAGE);  // 建议内核合并为大页

5.5 TLB 与上下文切换

每次进程切换通常需要刷新 TLB（除非使用 PCID/ASID）。这是上下文切换的一项隐性开销。

5.6 TLB 友好的数据布局

// TLB 友好: 顺序访问，每页利用率高
void tlb_friendly(double *a, long N) {
    for (long i = 0; i < N; i++)
        a[i] *= 2.0;  // 连续访问，一页 4KB = 512 个 double
}                     // 每 512 次访问才有一次 TLB miss

// TLB 不友好: 大步长跳跃，频繁跨页
void tlb_unfriendly(double *a, long N, int stride) {
    for (long i = 0; i < N; i += stride)
        a[i] *= 2.0;  // stride=1024 → 每次访问都是新的 TLB entry
}

// 数据结构布局: AoS vs SoA
// 差: AoS — 遍历单个字段时 Cache/TLB 利用率低
struct Particle_AoS {
    float x, y, z;      // 12B
    float vx, vy, vz;   // 12B
    // 28B/条 → 约 146条/4KB页
};

// 好: SoA — 高 Cache/TLB 利用率
struct Particles_SoA {
    float *x, *y, *z;
    float *vx, *vy, *vz;
};
// 更新 x 坐标: for(i) x[i] += dt;  每 4KB 页 1024 个全部有用!

6. Cache 体系结构

6.1 关键参数

参数	L1 Data	L2	L3
大小	32KB	256KB	8MB
组相联	8路	4路	16路
延迟	~4周期	~12周期	~40周期
是否每核私有	是	是	共享

6.2 虚拟 Cache vs 物理 Cache

类型	索引方式	优点	缺点
VIVT (虚拟索引虚拟标签)	纯虚拟地址	快，无需TLB	同义/异义问题
PIPT (物理索引物理标签)	纯物理地址	无歧义	需先查TLB，慢
VIPT (虚拟索引物理标签)	混合	现代主流方案	对Cache大小有限制

6.3 VIPT 实现技巧

当一个 L1 Cache 是 VIPT 时，如果 Cache大小 ≤ 组相联度 × 页大小，则虚拟索引位恰好等于物理索引位，可以直接并行进行 TLB 查找和 Cache 查找。

例：32KB L1D，8路组相联，64B 行 → 64组 → 6位索引
4KB 页，页内偏移 = 12位，包含这6位索引 → 索引位不跨页

6.4 预取（Prefetch）

硬件预取器自动检测访问模式并预取数据到 Cache：

预取器	检测模式
步长预取器	地址等差递增
空间预取器	相邻 Cache 行
流预取器	连续访问流

软件预取：__builtin_prefetch() 可手动预取。

#include <x86intrin.h>  // _mm_prefetch
// 提前预取 4 个 cache line
for (int i = 0; i < N; i++) {
    _mm_prefetch((char*)&src[i + 64], _MM_HINT_T0);  // 预取到 L1
    dst[i] = src[i] * 2;
}

7. 性能与优化

7.1 测量 Cache 效果

// 友好：步长为1，命中率高
for (int i = 0; i < N; i++) sum += a[i];

// 不友好：大步长，大量 cache miss
for (int i = 0; i < N; i++) sum += a[i * 64];  // 每次跳 64 个元素

两个线程修改同一 Cache 行的不同变量时，会导致 Cache 行在两个核心间反复传输。本来 1ns 的本地 L1 操作变成 ~100ns 的跨核通信，性能损失 10-100×！

// 问题代码：counter_a 和 counter_b 在同一 cache line
struct Counters_Bad { long counter_a; long counter_b; };

// 修复：padding 到不同 cache line
struct Counters_Good {
    long counter_a;
    char _pad1[64 - sizeof(long)];  // 填满 64B cache line
    long counter_b;
    char _pad2[64 - sizeof(long)];
};

// 或使用编译器对齐
struct Counters_Aligned {
    long counter_a;
} __attribute__((aligned(64)));
struct Counters_Aligned c1, c2;  // 在不同 cache line

bash

# 查看 cache line 大小
getconf LEVEL1_DCACHE_LINESIZE  # 通常是 64

7.3 矩阵乘法分块（Tiling）

// 完整的分块矩阵乘法 — 确保3个分块放入 L1 Cache
// L1D=32KB, 3×B²×8 ≤ 32KB → B ≤ 36
void matmul_blocked(int N, double *A, double *B, double *C) {
    int BLOCK = 32;
    memset(C, 0, N * N * sizeof(double));
    for (int ii = 0; ii < N; ii += BLOCK)
        for (int jj = 0; jj < N; jj += BLOCK)
            for (int kk = 0; kk < N; kk += BLOCK)
                for (int i = ii; i < ii+BLOCK && i < N; i++)
                    for (int k = kk; k < kk+BLOCK && k < N; k++) {
                        double r = A[i*N + k];
                        for (int j = jj; j < jj+BLOCK && j < N; j++)
                            C[i*N + j] += r * B[k*N + j];
                    }
}

bash

# 用 perf 验证 Cache 效果
perf stat -e LLC-loads,LLC-load-misses \
    -e L1-dcache-loads,L1-dcache-load-misses \
    ./matmul_blocked

8. 从微架构到代码：我们写程序时真正会踩到什么

8.1 局部性为什么决定了“同样 O(n)，快慢能差很多”

算法复杂度只描述增长趋势，但 CPU 真正喜欢的是局部性好的访问模式。

局部性	含义	代码里的典型体现
时间局部性	刚访问过的数据很快还会再访问	热点计数器、循环变量、缓存对象
空间局部性	相邻数据很快会被访问	连续数组、slice 顺序遍历

这就是为什么：

[]T 顺序遍历通常明显快于链表遍历
AoS 和 SoA 在数值计算场景差别巨大
同样是哈希表，key/value 布局不同性能能差很多

8.2 对齐不是“编译器细节”，而是实际性能问题

CPU 和内存系统倾向于按 cache line、字长、对齐边界来取数。数据不对齐时，可能带来：

额外的访存拆分
更多 cache line 访问
某些架构上更严格的对齐要求

struct Bad {
    char a;
    long b;
    char c;
};

这个结构逻辑字段很少，但由于对齐会插入 padding。对我们写代码的启发是：

结构体字段顺序会影响大小
热字段应尽量聚集
跨线程频繁写的字段要避免落在同一 cache line

8.3 为什么堆和栈的性能感受差这么大

很多工程师只知道“栈快、堆慢”，但真正原因是：

维度	栈	堆
分配成本	仅移动栈指针	需要 allocator 参与
局部性	通常很好	取决于分配器和碎片
生命周期	函数级，天然明确	需要 GC 或手动回收
额外成本	很低	可能引入 GC、锁、碎片

在 Go 里，这会进一步体现为：

text

逃逸到堆
  → 分配次数增加
  → GC 压力上升
  → cache / TLB 命中下降
  → 延迟抖动更明显

所以“减少逃逸”不是为了编译器考试，而是为了：

降低分配和 GC 成本
提高局部性
降低尾延迟

8.4 分支预测为什么和业务代码强相关

CPU 很怕“完全随机”的分支。

for _, x := range data {
    if x > threshold {
        sum += x
    }
}

如果 x > threshold 的分布高度随机，分支预测失败率就会上去。结果就是：

流水线被冲刷
已经发射的指令白做了
吞吐显著下降

这也是为什么很多高性能代码会：

先排序/分桶再处理
批量处理同类数据
尽量减少不可预测分支

8.5 一个从数据结构到 CPU 的完整性能链路

mermaid

flowchart LR
    A["数据结构选择"] --> B["内存布局"]
    B --> C["Cache/TLB 命中率"]
    C --> D["CPU stall / 分支预测 / 一致性开销"]
    D --> E["吞吐 / RT / P99"]

例如：

链表改成 slice：通常先改善的是 cache miss，不只是“少了指针”
大对象频繁逃逸到堆：通常先恶化的是分配/GC，再恶化访存局部性
多线程共享一个热点计数器：先恶化的是 cache line 抖动，而不是算法复杂度

8.6 线上排障时怎么判断是不是微架构层问题

现象	可能原因	先看什么
CPU 很高但吞吐不升	cache miss / false sharing / 分支预测差	`perf stat`, `perf top`
多核扩展性很差	锁竞争、cache line ping-pong	profile、padding 验证
延迟抖动明显	GC、TLB miss、NUMA 远端访问	`perf`, `numastat`, runtime 指标
某段循环理论 O(n) 但异常慢	数据布局差、局部性差	benchmark、cache miss 指标

常见命令：

bash

perf stat -e cycles,instructions,branches,branch-misses,cache-misses ./app
perf top
numastat -p <pid>

8.7 一条实战原则

text

先选对数据结构和内存布局，
再看并发模型和热点共享，
最后再谈指令级优化和手写技巧。

大多数程序性能问题，根因不在汇编层面，而在：

数据结构选错
对象布局差
堆分配过多
跨核共享太重
下游阻塞让 CPU 优化失去意义

9. SIMD 与向量化 — 一条指令处理多个数据

9.1 什么是 SIMD

SIMD（Single Instruction, Multiple Data）是 CPU 提供的一类特殊指令，能在一个时钟周期内对多个数据元素执行相同操作。

text

标量操作:
  a[0] += b[0]  → 1 条指令
  a[1] += b[1]  → 1 条指令
  a[2] += b[2]  → 1 条指令
  a[3] += b[3]  → 1 条指令
  共 4 条指令

SIMD 操作 (128-bit SSE):
  a[0..3] += b[0..3]  → 1 条指令！
  4× 加速（理论上限）

9.2 各平台的 SIMD 指令集

指令集	寄存器宽度	平台	代表指令
SSE2	128-bit (16B)	x86 (2001+)	`_mm_add_epi32`
AVX2	256-bit (32B)	x86 (2013+)	`_mm256_add_epi32`
AVX-512	512-bit (64B)	x86 (2017+)	`_mm512_add_epi32`
NEON	128-bit (16B)	ARM (ARMv7+)	`vaddq_s32`
SVE/SVE2	128-2048 bit (可变)	ARM (ARMv9)	向量长度无关编程

#include <immintrin.h>

// SSE2: 一次处理 4 个 float
void add_sse(float *a, float *b, float *c, int n) {
    for (int i = 0; i < n; i += 4) {
        __m128 va = _mm_loadu_ps(&a[i]);
        __m128 vb = _mm_loadu_ps(&b[i]);
        __m128 vc = _mm_add_ps(va, vb);
        _mm_storeu_ps(&c[i], vc);
    }
}

// AVX2: 一次处理 8 个 float
void add_avx2(float *a, float *b, float *c, int n) {
    for (int i = 0; i < n; i += 8) {
        __m256 va = _mm256_loadu_ps(&a[i]);
        __m256 vb = _mm256_loadu_ps(&b[i]);
        __m256 vc = _mm256_add_ps(va, vb);
        _mm256_storeu_ps(&c[i], vc);
    }
}

9.3 编译器自动向量化

现代编译器（GCC、Clang、MSVC）能自动将简单循环向量化，但有严格条件：

条件	说明	违反时的后果
无循环依赖	`a[i]` 不依赖 `a[i-1]` 的结果	无法向量化
无分支	循环体内没有 if/else	可能用 mask 处理，但效率降低
连续访问	数组顺序访问，步长为 1	非连续访问需要 gather/scatter
对齐	数据按 16/32/64 字节对齐	用 unaligned load，略慢
已知迭代次数	编译时或运行时能确定	可能无法展开

// ✅ 编译器能自动向量化
for (int i = 0; i < n; i++)
    c[i] = a[i] + b[i];

// ❌ 有循环依赖，无法向量化
for (int i = 1; i < n; i++)
    a[i] = a[i-1] + b[i];

// ❌ 有分支，向量化困难
for (int i = 0; i < n; i++)
    if (a[i] > 0) c[i] = a[i] * 2;
    else c[i] = 0;

bash

# 查看编译器是否向量化了
gcc -O2 -ftree-vectorize -fopt-info-vec-optimized -c code.c
# 或
clang -O2 -Rpass=loop-vectorize -c code.c

9.4 SIMD 在实际系统中的应用

系统/库	SIMD 用途	为什么需要
SwissTable	一次比较 16 个 ctrl 字节	hash 表查找加速
memcpy / memmove	批量内存拷贝	基础库性能
JSON 解析 (simdjson)	批量字符分类、转义检测	解析速度提升 10×
字符串搜索	批量字符匹配	`strings.Index` 加速
CRC32 / 校验和	批量数据校验	网络、存储校验
压缩 (LZ4/Snappy)	批量比较、拷贝	压缩解压加速
数据库 (ClickHouse)	列式计算、过滤、聚合	OLAP 查询加速
Go runtime	`memhash`(AES-NI)、`memmove`、`bytes.Equal`	基础性能

9.5 Go 中的 SIMD

Go 不直接暴露 SIMD intrinsics，但 runtime 和标准库内部大量使用：

text

Go runtime 中的 SIMD 使用:
  - runtime/asm_amd64.s: memmove, memclr 用 AVX2/SSE2
  - runtime/alg.go: memhash 用 AES-NI
  - bytes/bytes.go: Equal, Index 用 SSE4.2/AVX2
  - crypto/aes: 用 AES-NI 硬件加速
  - math/big: 用 ADX/MULX 加速大数运算

如果需要在 Go 中手写 SIMD：

// 方式 1: 汇编文件 (最常见)
// file: add_amd64.s
// func addSIMD(a, b, c []float32)
// TEXT ·addSIMD(SB), NOSPLIT, $0
//   VMOVUPS (AX), Y0
//   VMOVUPS (BX), Y1
//   VADDPS Y0, Y1, Y2
//   VMOVUPS Y2, (CX)
//   RET

// 方式 2: 使用第三方库 (如 gonum, viterin/go-simd)

9.6 Rust 和 C++ 中的 SIMD

rust

// Rust: 使用 std::simd (nightly) 或 packed_simd
use std::simd::f32x8;

fn add_simd(a: &[f32], b: &[f32], c: &mut [f32]) {
    for i in (0..a.len()).step_by(8) {
        let va = f32x8::from_slice(&a[i..]);
        let vb = f32x8::from_slice(&b[i..]);
        let vc = va + vb;
        vc.copy_to_slice(&mut c[i..]);
    }
}

cpp

// C++: 使用 intrinsics 或 std::experimental::simd
#include <immintrin.h>

void process(float* data, int n) {
    for (int i = 0; i < n; i += 8) {
        __m256 v = _mm256_loadu_ps(&data[i]);
        v = _mm256_mul_ps(v, _mm256_set1_ps(2.0f));
        _mm256_storeu_ps(&data[i], v);
    }
}

9.7 SIMD 的限制和陷阱

问题	说明
频率降低	AVX-512 可能导致 CPU 降频（功耗过高）
数据对齐	未对齐的 load/store 可能更慢
分支处理	SIMD 不擅长处理条件分支，需要用 mask
可移植性	不同平台指令集不同，需要多版本或抽象层
调试困难	SIMD 代码不容易单步调试
编译器已经很好	简单循环编译器自动向量化，手写不一定更快

9.8 什么时候该关注 SIMD

text

大多数业务代码: 不需要手写 SIMD
  → 编译器自动向量化 + 标准库已经用了 SIMD
  → 瓶颈通常在 I/O、网络、数据库，不在计算

需要关注 SIMD 的场景:
  → 数据密集型计算（数值、图像、音视频）
  → 基础库开发（hash、压缩、序列化）
  → 性能关键路径且已确认 CPU bound
  → 批量数据处理（OLAP、日志分析）

一条原则：先让编译器自动向量化（写简单循环、避免依赖和分支），只有 profile 确认瓶颈在计算时才考虑手写 SIMD。

10. 语言特性与硬件的深度关联——经典案例系统分析

10.1 案例 1: Go struct 内存对齐与 cache line 的关系

// 案例: 两个看似等价的 struct，性能差 40%

// 差的布局 (56 字节，跨 cache line)
type Bad struct {
    a bool    // 1B
    b int64   // 8B (需要对齐到 8B 边界 → 7B padding)
    c bool    // 1B
    d int64   // 8B (又 7B padding)
    e bool    // 1B
    f int64   // 8B (又 7B padding)
}
// sizeof(Bad) = 1+7+8+1+7+8+1+7+8 = 48B (实际可能更大)

// 好的布局 (32 字节，1 个 cache line 内)
type Good struct {
    b int64   // 8B
    d int64   // 8B
    f int64   // 8B
    a bool    // 1B
    c bool    // 1B
    e bool    // 1B
    // 5B padding
}
// sizeof(Good) = 8+8+8+1+1+1+5 = 32B

// 编译器的对齐规则:
//   每个字段的偏移量必须是其大小的整数倍
//   int64 必须在 8B 边界 → 前面的 bool 后面会有 7B padding
//   struct 整体大小必须是最大字段大小的整数倍

// 性能影响:
//   Bad: 48B → 可能跨越 2 个 cache line (64B)
//        → 读取一个 Bad 可能需要 2 次 cache line load
//   Good: 32B → 一定在 1 个 cache line 内
//         → 读取一个 Good 只需 1 次 cache line load

// 数组场景更明显:
//   []Bad (1000个): 48KB → 750 个 cache line
//   []Good (1000个): 32KB → 500 个 cache line
//   遍历时 Good 版本 cache miss 少 33%

10.2 案例 2: 编译器优化与寄存器分配——为什么小函数要内联

// 案例: 函数调用的隐藏代价

func add(a, b int) int { return a + b }  // 极简函数

// 不内联时的汇编 (go build -gcflags="-l"):
//   CALL add(SB)
//   → 保存 caller-saved 寄存器到栈
//   → 设置参数 (AX, BX)
//   → CALL 指令 (push PC, jump)
//   → 函数序言 (检查栈空间, 可能触发栈增长)
//   → 执行 ADD
//   → RET (pop PC, jump back)
//   → 恢复寄存器
//   总代价: ~5-15ns (vs ADD 指令本身 <1ns)

// 内联后:
//   编译器直接将 a+b 替换到调用处
//   → 1 条 ADD 指令
//   → 无函数调用开销
//   → 变量可能直接留在寄存器中（不需要 load/store）

// Go 的内联决策:
//   函数体 AST 节点加权成本 < 80 → 内联
//   内联后的额外好处:
//     1. 逃逸分析更精确（内联后变量可能不逃逸）
//     2. 常量传播（如果参数是常量，编译器可以直接计算结果）
//     3. 死代码消除（如果 if 分支的条件在编译期可确定）

// 实测: 热循环中调用小函数
//   不内联: 100M 次调用 → ~1.2s (每次 ~12ns)
//   内联后: 100M 次调用 → ~0.1s (每次 ~1ns)
//   差距: 12× ！

10.3 案例 3: 栈分配 vs 堆分配——编译器决策对 GC 的影响

// 案例: 同样的逻辑，一个在栈上一个在堆上，性能差 10×

// 栈分配 (不逃逸)
func stackAlloc() int {
    x := 42        // x 在栈上
    return x * 2   // x 的生命周期 = 函数返回前 → 栈分配
}

// 堆分配 (逃逸)
func heapAlloc() *int {
    x := 42        // x 逃逸到堆上
    return &x      // 返回了 x 的地址 → 调用方持有指针 → 必须堆分配
}

// 硬件层面的差异:
//
// 栈分配:
//   编译器: SUB SP, #8 (移动栈指针，分配 8B)
//   → 1 条指令，~0.3ns
//   → 释放: 函数返回时 ADD SP, #8 → 自动释放
//   → 不需要 GC 参与
//   → 栈内存总是在 L1 cache 中（因为刚被使用过）
//
// 堆分配:
//   runtime: mallocgc(8, ...) → 从 mcache/mcentral/mheap 分配
//   → 需要检查 mcache 的 span → 可能需要加锁
//   → ~25-50ns (比栈分配慢 100×)
//   → 释放: 等 GC 标记-清除 → 不确定何时释放
//   → 堆内存可能不在 cache 中（分散在堆的各处）
//   → GC 需要扫描这个对象的指针 → 增加 GC 标记时间

// 量化影响 (1M 次分配):
//   栈: 1M × 0.3ns = 0.3ms
//   堆: 1M × 40ns = 40ms + GC 暂停时间
//   差距: 100× + GC 压力

10.4 案例 4: 数组 vs 链表——CPU 预取器的视角

// 案例: 遍历 100 万个 int，数组 vs 链表

// 数组遍历
func sumArray(arr []int) int {
    sum := 0
    for _, v := range arr {
        sum += v
    }
    return sum
}

// 链表遍历
type Node struct {
    val  int
    next *Node
}
func sumList(head *Node) int {
    sum := 0
    for p := head; p != nil; p = p.next {
        sum += p.val
    }
    return sum
}

// CPU 预取器的行为:
//
// 数组:
//   内存布局: [v0][v1][v2][v3]...[v999999] (连续 8MB)
//   CPU 预取器检测到"步长 = 8B 的顺序访问模式"
//   → 自动预取后续 cache line 到 L1
//   → 几乎每次访问都是 L1 hit (~1ns)
//   → 总时间: 1M × 1ns ≈ 1ms
//
// 链表:
//   内存布局: Node@0x1000 → Node@0x5000 → Node@0x2800 → ... (随机分散)
//   CPU 预取器无法预测下一个节点的地址（取决于 next 指针的值）
//   → 每次访问都可能 cache miss
//   → L3 hit: ~10ns, 主存: ~100ns
//   → 总时间: 1M × 30ns(平均) ≈ 30ms
//
// 差距: 数组比链表快 30× ！

// 实测 benchmark (Go, n=1M):
//   BenchmarkSumArray-8    1.2ms
//   BenchmarkSumList-8     35ms
//   比值: 29×

// 这就是为什么:
//   - Go slice 比 container/list 几乎总是更快
//   - Redis 用 ziplist/listpack 而非真正的链表存储小列表
//   - 数据库索引用 B+ 树（节点内数组）而非二叉树

// 案例: 4 个 goroutine 各自递增自己的计数器，但性能极差

// 差的设计: 4 个计数器紧挨着
type BadCounters struct {
    c0 int64  // offset 0
    c1 int64  // offset 8
    c2 int64  // offset 16
    c3 int64  // offset 24
}
// 4 个 int64 = 32B → 全部在同一个 cache line (64B) 内！

// 好的设计: 每个计数器独占一个 cache line
type GoodCounters struct {
    c0 int64
    _  [56]byte  // padding to 64B
    c1 int64
    _  [56]byte
    c2 int64
    _  [56]byte
    c3 int64
    _  [56]byte
}

// 硬件层面发生了什么:
//
// BadCounters:
//   Core 0 写 c0 → 标记 cache line 为 Modified (MESI)
//   Core 1 写 c1 → 需要先 Invalidate Core 0 的 cache line
//                 → Core 0 的 cache line 变为 Invalid
//                 → Core 1 从 L3/主存重新加载 → 标记为 Modified
//   Core 0 再写 c0 → 又要 Invalidate Core 1 的...
//   → cache line 在核间"乒乓" → 每次写入 ~50-100ns (vs 正常 ~1ns)
//
// GoodCounters:
//   每个计数器在独立的 cache line
//   Core 0 写 c0 → 只影响自己的 cache line
//   Core 1 写 c1 → 只影响自己的 cache line
//   → 无冲突 → 每次写入 ~1ns

// 实测:
//   BadCounters:  4 goroutine × 100M 递增 → 12s (每次 ~30ns)
//   GoodCounters: 4 goroutine × 100M 递增 → 0.4s (每次 ~1ns)
//   差距: 30× ！

// Go 标准库的实际应用:
//   sync.Pool 的 poolLocal 结构体就用了 cache line padding:
//   type poolLocal struct {
//       poolLocalInternal
//       pad [128 - unsafe.Sizeof(poolLocalInternal{})%128]byte
//   }

参考

CSAPP 第4章：处理器体系结构
CSAPP 第6章：存储器层次结构
Agner Fog's microarchitecture guide
Apple Silicon
What Every Programmer Should Know About Memory

CPU 微架构与 TLB/Cache ​

1. 处理器微架构基础 ​

1.1 指令执行的基本流程 ​

1.2 流水线的演变 ​

1.3 μop（微操作）架构 ​

2. 指令集架构对比（ISA） ​

2.1 RISC vs CISC ​

2.2 多平台架构对比 ​

Intel/AMD x86-64 ​

Apple Silicon (M 系列) ​

ARM 服务器 (AWS Graviton / 华为鲲鹏) ​

RISC-V ​

2.3 CPU vs GPU vs NPU ​

3. 指令级并行 (ILP) ​

3.1 超标量 ​

3.2 乱序执行 (Out-of-Order, OoO) ​

3.3 数据冒险与转发网络 ​

3.4 分支预测 ​

4. 多核与多线程 ​

4.1 多核架构 ​

4.2 SMT（同时多线程，Intel 超线程） ​

4.3 Cache 一致性协议：MESI ​

4.4 MESI 状态转换 — 完整图解 ​

4.5 分支预测失败的性能影响量化 ​

5. TLB（Translation Lookaside Buffer） ​

5.1 TLB 的作用 ​

5.2 TLB 的组织结构 ​

5.3 TLB 缺失的代价 ​

5.4 大页（Huge Pages） ​

5.5 TLB 与上下文切换 ​

5.6 TLB 友好的数据布局 ​

6. Cache 体系结构 ​

6.1 关键参数 ​

6.2 虚拟 Cache vs 物理 Cache ​

6.3 VIPT 实现技巧 ​

6.4 预取（Prefetch） ​

7. 性能与优化 ​

7.1 测量 Cache 效果 ​

7.2 False Sharing（伪共享） ​

7.3 矩阵乘法分块（Tiling） ​

8. 从微架构到代码：我们写程序时真正会踩到什么 ​

8.1 局部性为什么决定了“同样 O(n)，快慢能差很多” ​

8.2 对齐不是“编译器细节”，而是实际性能问题 ​

8.3 为什么堆和栈的性能感受差这么大 ​

8.4 分支预测为什么和业务代码强相关 ​

8.5 一个从数据结构到 CPU 的完整性能链路 ​

8.6 线上排障时怎么判断是不是微架构层问题 ​

8.7 一条实战原则 ​

9. SIMD 与向量化 — 一条指令处理多个数据 ​

9.1 什么是 SIMD ​

9.2 各平台的 SIMD 指令集 ​

9.3 编译器自动向量化 ​

9.4 SIMD 在实际系统中的应用 ​

9.5 Go 中的 SIMD ​

9.6 Rust 和 C++ 中的 SIMD ​

9.7 SIMD 的限制和陷阱 ​

9.8 什么时候该关注 SIMD ​

10. 语言特性与硬件的深度关联——经典案例系统分析 ​

10.1 案例 1: Go struct 内存对齐与 cache line 的关系 ​

10.2 案例 2: 编译器优化与寄存器分配——为什么小函数要内联 ​

10.3 案例 3: 栈分配 vs 堆分配——编译器决策对 GC 的影响 ​

10.4 案例 4: 数组 vs 链表——CPU 预取器的视角 ​

10.5 案例 5: False Sharing——多核 CPU 的隐形杀手 ​

参考 ​

💬 文章评论

CPU 微架构与 TLB/Cache

1. 处理器微架构基础

1.1 指令执行的基本流程

1.2 流水线的演变

1.3 μop（微操作）架构

2. 指令集架构对比（ISA）

2.1 RISC vs CISC

2.2 多平台架构对比

Intel/AMD x86-64

Apple Silicon (M 系列)

ARM 服务器 (AWS Graviton / 华为鲲鹏)

RISC-V

2.3 CPU vs GPU vs NPU

3. 指令级并行 (ILP)

3.1 超标量

3.2 乱序执行 (Out-of-Order, OoO)

3.3 数据冒险与转发网络

3.4 分支预测

4. 多核与多线程

4.1 多核架构

4.2 SMT（同时多线程，Intel 超线程）

4.3 Cache 一致性协议：MESI

4.4 MESI 状态转换 — 完整图解

4.5 分支预测失败的性能影响量化

5. TLB（Translation Lookaside Buffer）

5.1 TLB 的作用

5.2 TLB 的组织结构

5.3 TLB 缺失的代价

5.4 大页（Huge Pages）

5.5 TLB 与上下文切换

5.6 TLB 友好的数据布局

6. Cache 体系结构

6.1 关键参数

6.2 虚拟 Cache vs 物理 Cache

6.3 VIPT 实现技巧

6.4 预取（Prefetch）

7. 性能与优化

7.1 测量 Cache 效果

7.2 False Sharing（伪共享）

7.3 矩阵乘法分块（Tiling）

8. 从微架构到代码：我们写程序时真正会踩到什么

8.1 局部性为什么决定了“同样 O(n)，快慢能差很多”

8.2 对齐不是“编译器细节”，而是实际性能问题

8.3 为什么堆和栈的性能感受差这么大

8.4 分支预测为什么和业务代码强相关

8.5 一个从数据结构到 CPU 的完整性能链路

8.6 线上排障时怎么判断是不是微架构层问题

8.7 一条实战原则

9. SIMD 与向量化 — 一条指令处理多个数据

9.1 什么是 SIMD

9.2 各平台的 SIMD 指令集

9.3 编译器自动向量化

9.4 SIMD 在实际系统中的应用

9.5 Go 中的 SIMD

9.6 Rust 和 C++ 中的 SIMD

9.7 SIMD 的限制和陷阱

9.8 什么时候该关注 SIMD

10. 语言特性与硬件的深度关联——经典案例系统分析

10.1 案例 1: Go struct 内存对齐与 cache line 的关系

10.2 案例 2: 编译器优化与寄存器分配——为什么小函数要内联

10.3 案例 3: 栈分配 vs 堆分配——编译器决策对 GC 的影响

10.4 案例 4: 数组 vs 链表——CPU 预取器的视角

10.5 案例 5: False Sharing——多核 CPU 的隐形杀手

参考