第二章 目标架构分析：CPU微架构特征、指令集差异、内存层次结构对编译的影响

做编译器适配，说白了就是跟硬件谈恋爱。你得摸透对方的脾气，才知道怎么哄它干活。

我记得刚入行那会儿，接手一个项目，代码在x86上跑得飞快，换到ARM平台直接卡成PPT。我当时还纳闷：同样的C代码，怎么换个CPU就拉胯了？后来才明白——编译器不懂硬件，就像厨师不懂灶台的火候，再好的食材也白搭。

这一章，我们就来聊聊编译器眼中的CPU长什么样。我会从三个维度展开：微架构特征、指令集差异、内存层次结构。嗯，这三个东西，决定了你的代码最终是“飞”还是“爬”。

2.1 CPU微架构特征：编译器该看什么？

微架构，说白了就是CPU内部怎么干活。不同厂商、不同代际的CPU，微架构天差地别。编译器要做的，就是根据这些特征，生成最合适的指令序列。

2.1.1 流水线与指令调度

现代CPU都是流水线架构。一条指令要经过取指、译码、执行、访存、写回等多个阶段。编译器如果能合理安排指令顺序，就能让流水线“吃饱”，避免空转。

我遇到过最典型的例子，是循环展开。你想想看，如果循环体里有一条load指令，后面紧跟着一条用这个load结果的add指令，那CPU就得等——这叫“数据冒险”。

举个例子，下面这段代码：

// 原始代码
for (int i = 0; i < N; i++) {
    a[i] = b[i] + c[i];
}

编译器可能会把它展开成这样：

// 展开后，减少循环控制开销，同时给指令调度更多空间
for (int i = 0; i < N; i += 4) {
    a[i]   = b[i]   + c[i];
    a[i+1] = b[i+1] + c[i+1];
    a[i+2] = b[i+2] + c[i+2];
    a[i+3] = b[i+3] + c[i+3];
}

但展开多少合适？这取决于CPU的发射宽度和功能单元数量。我曾经在某个项目里，把循环展开因子从4调到8，性能反而下降了——因为寄存器不够用了，导致寄存器溢出。嗯，这里要注意：过犹不及。

2.1.2 超标量与乱序执行

现在的CPU大多支持超标量（一次发射多条指令）和乱序执行（不按程序顺序执行）。编译器可以利用这一点，把不相关的指令穿插在一起，提高并行度。

我个人习惯在写关键循环时，手动把计算和内存访问交错开。比如：

// 不好的写法：连续load，连续计算
float a = load(ptr1);
float b = load(ptr2);
float c = a + b;
float d = load(ptr3);
float e = load(ptr4);
float f = d + e;

// 好的写法：load和计算交错，让CPU能并行处理
float a = load(ptr1);
float b = load(ptr2);
float c = a + b;
float d = load(ptr3);
float e = load(ptr4);
float f = d + e;

等等，上面两个例子看起来一样？其实不一样——第二个版本里，c = a + b 和 d = load(ptr3) 没有数据依赖，CPU可以同时执行。但第一个版本如果连续load再连续计算，load的延迟可能会拖慢后续计算。

2.2 指令集差异：不只是“指令不同”这么简单

指令集是CPU和编译器之间的“协议”。不同指令集，能用的指令、寄存器数量、寻址方式都不一样。编译器必须针对目标指令集做专门的代码生成。

2.2.1 RISC vs CISC：哲学之争

RISC（精简指令集）和CISC（复杂指令集）是两条路。RISC指令简单、长度固定，适合流水线；CISC指令复杂、长度可变，一条指令能干很多事。

我做过一个对比实验：同样的排序算法，在ARM（RISC）和x86（CISC）上编译。ARM版本指令数多，但每条指令执行快；x86版本指令数少，但有些复杂指令（比如带内存操作数的add）延迟高。最终性能差不多，但编译器策略完全不同。

特性	RISC（如ARM、RISC-V）	CISC（如x86）
指令长度	固定（通常4字节）	可变（1-15字节）
寄存器数量	多（通常16-32个通用寄存器）	少（x86-64有16个，但历史原因部分寄存器有特殊用途）
寻址方式	少（通常只有基址+偏移）	多（基址+偏移+比例+立即数等组合）
内存操作	只有load/store指令能访问内存	很多指令可以直接操作内存

对于编译器来说，RISC架构更容易做指令调度，因为所有内存访问都是显式的。而CISC架构下，编译器需要小心处理那些“隐含”的内存操作——比如一条 add [rax], rbx 既读了内存又写了内存，编译器得确保没有冲突。

2.2.2 SIMD指令：向量化的利器

现代CPU几乎都支持SIMD（单指令多数据）。x86有SSE/AVX，ARM有NEON/SVE。编译器如果能自动向量化，性能提升非常可观。

我曾经优化过一个图像处理库，核心是一个像素点乘循环。手动写成NEON内联汇编后，速度提升了4倍。但自动向量化并不总是靠谱——编译器有时候识别不了循环的向量化潜力。

// 不加restrict，编译器保守处理
void add_arrays(float *a, float *b, float *c, int n) {
    for (int i = 0; i < n; i++) {
        a[i] = b[i] + c[i];
    }
}

// 加restrict，告诉编译器指针不重叠
void add_arrays_restrict(float *restrict a, float *restrict b, float *restrict c, int n) {
    for (int i = 0; i < n; i++) {
        a[i] = b[i] + c[i];
    }
}

2.3 内存层次结构：编译器眼中的“距离”

CPU和内存之间的速度差距，是计算机体系结构里最头疼的问题。寄存器访问只要1个周期，L1缓存3-5个周期，L2缓存10-20个周期，主存要上百个周期。编译器必须想办法让数据尽量待在“近处”。

2.3.1 缓存行与空间局部性

缓存是以“行”为单位加载的，通常是64字节。如果你顺序访问数组，第一个元素会触发一次缓存行加载，后续15个元素（假设是4字节的int）都在同一行里，访问极快。这就是空间局部性。

但如果你跳着访问，比如按列遍历一个二维数组，那缓存行就白加载了——每次都要重新从内存取。

// 好的访问模式：按行遍历（空间局部性好）
for (int i = 0; i < ROWS; i++) {
    for (int j = 0; j < COLS; j++) {
        sum += matrix[i][j];
    }
}

// 坏的访问模式：按列遍历（空间局部性差）
for (int j = 0; j < COLS; j++) {
    for (int i = 0; i < ROWS; i++) {
        sum += matrix[i][j];
    }
}

我做过测试，在同样数据量下，按列遍历比按行遍历慢了将近10倍。编译器能做的，就是尽量保持循环的访问顺序和内存布局一致。有些编译器会做“循环交换”优化，把内外层循环互换，就是为了改善空间局部性。

2.3.2 缓存大小与分块

L1缓存通常只有32KB-64KB。如果你的数据超过了缓存大小，就会发生“缓存抖动”——频繁地换入换出。这时候，编译器可以采用“分块”技术，把大数组切成小块，让每一块都能塞进缓存。

举个例子，矩阵乘法：

// 普通矩阵乘法，缓存利用率低
for (int i = 0; i < N; i++) {
    for (int j = 0; j < N; j++) {
        float sum = 0;
        for (int k = 0; k < N; k++) {
            sum += A[i][k] * B[k][j];
        }
        C[i][j] = sum;
    }
}

// 分块矩阵乘法，提高缓存命中率
#define BLOCK_SIZE 64
for (int i = 0; i < N; i += BLOCK_SIZE) {
    for (int j = 0; j < N; j += BLOCK_SIZE) {
        for (int k = 0; k < N; k += BLOCK_SIZE) {
            // 处理一个BLOCK_SIZE x BLOCK_SIZE的子块
            for (int ii = i; ii < i + BLOCK_SIZE; ii++) {
                for (int jj = j; jj < j + BLOCK_SIZE; jj++) {
                    float sum = C[ii][jj];
                    for (int kk = k; kk < k + BLOCK_SIZE; kk++) {
                        sum += A[ii][kk] * B[kk][jj];
                    }
                    C[ii][jj] = sum;
                }
            }
        }
    }
}

分块大小怎么选？我一般会看目标CPU的L1缓存大小。比如L1数据缓存是32KB，那分块大小可以设为 sqrt(32KB / sizeof(float)) ≈ 90。但实际中还要考虑缓存关联度、同时存在的数据等因素，所以通常取64或128作为经验值。

2.4 知识体系总览

下面这张图，是我自己总结的“编译器适配性能调优”知识框架。你可以把它当作一个地图，后续章节都会围绕这些点展开。

这张图里，三个分支最终汇聚到“编译器优化策略”。你想想看，指令调度要考虑流水线，寄存器分配要考虑指令集，循环变换要考虑缓存——它们不是孤立的。

我个人习惯在做性能调优时，先看内存访问模式，再看指令选择，最后调指令顺序。这个顺序不是绝对的，但能帮我快速定位瓶颈。比如，如果缓存命中率已经很低了，那指令调度再完美也没用——CPU大部分时间都在等数据。

好了，这一章的内容就到这里。下一章我们会深入具体案例，看看怎么在x86和ARM上分别做针对性优化。到时候我会拿出一些真实的性能数据，咱们一起分析。

---