预取与预加载：软件预取指令、数据预取、指令预取

大家好，我是你们的老朋友。今天我们来聊一个让程序“飞”起来的技术——预取与预加载。

你想想看，CPU 跑得飞快，内存却慢吞吞的。这个速度差距，就是我们常说的“内存墙”。我刚开始做性能优化那会儿，经常遇到一个现象：算法复杂度明明很低，但跑起来就是慢。后来一查，发现 CPU 大部分时间都在等数据从内存里搬过来。说白了，就是缓存没命中，CPU 在那干等。

那怎么办？预取就是干这个的。它让 CPU 提前把数据从内存搬到缓存里，等真正要用的时候，数据已经在 L1 缓存里等着了。嗯，这里要注意，预取不是万能的，用不好反而会拖慢程序。

1. 预取的基本原理

先看一张图，帮你理解预取在整个存储层次中的位置。

这张图展示了预取的核心逻辑。正常的数据流动是 CPU 逐级向上请求，如果 L1 没命中，就去 L2 找，再没命中就去 L3，最后到主存。这个过程叫“缓存缺失”，代价非常大。预取就是提前把数据从主存搬到 L1 或 L2，等 CPU 真正需要时，直接命中。

2. 软件预取指令

软件预取，说白了就是程序员手动告诉 CPU：“嘿，这个地址的数据你帮我提前拿一下。” 在 x86 平台上，对应的指令是 PREFETCH 系列。在 GCC 里，我们可以用内置函数 __builtin_prefetch。

void __builtin_prefetch(const void *addr, int rw, int locality);

我个人习惯在遍历大数组时使用预取。比如下面这个例子：

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#define N 100000000
#define PREFETCH_DISTANCE 64

void sum_array_with_prefetch(int *arr, int n) {
    long long sum = 0;
    for (int i = 0; i < n; i++) {
        // 预取 64 个元素之后的数据
        __builtin_prefetch(&arr[i + PREFETCH_DISTANCE], 0, 1);
        sum += arr[i];
    }
    printf("Sum: %lld\n", sum);
}

void sum_array_normal(int *arr, int n) {
    long long sum = 0;
    for (int i = 0; i < n; i++) {
        sum += arr[i];
    }
    printf("Sum: %lld\n", sum);
}

int main() {
    int *arr = (int*)malloc(N * sizeof(int));
    for (int i = 0; i < N; i++) arr[i] = i % 1000;

    clock_t start, end;
    
    start = clock();
    sum_array_normal(arr, N);
    end = clock();
    printf("Normal time: %.3f ms\n", (double)(end - start) * 1000 / CLOCKS_PER_SEC);
    
    start = clock();
    sum_array_with_prefetch(arr, N);
    end = clock();
    printf("Prefetch time: %.3f ms\n", (double)(end - start) * 1000 / CLOCKS_PER_SEC);
    
    free(arr);
    return 0;
}

3. 数据预取策略

数据预取分为两种：硬件预取和软件预取。硬件预取是 CPU 自动做的，比如 Intel 的 硬件预取器（Hardware Prefetcher），它会检测连续的内存访问模式，自动把后面的数据拉进来。

但硬件预取不是万能的。我在项目中遇到过一种情况：遍历一个链表，每个节点在内存里是随机分布的。硬件预取器根本猜不到下一个节点在哪，这时候就需要软件预取上场了。

3.1 链表遍历的预取优化

struct Node {
    int data;
    struct Node *next;
};

void traverse_with_prefetch(struct Node *head) {
    struct Node *cur = head;
    struct Node *prefetch_node = head;
    int prefetch_ahead = 4;  // 提前预取 4 个节点
    
    while (cur != NULL) {
        // 提前预取后面的节点
        for (int i = 0; i < prefetch_ahead && prefetch_node != NULL; i++) {
            __builtin_prefetch(prefetch_node->next, 0, 1);
            prefetch_node = prefetch_node->next;
        }
        // 处理当前节点
        process(cur);
        cur = cur->next;
    }
}

你看，这里我手动预取了 cur->next 的 next，也就是提前把后面几个节点的数据拉到缓存里。这样当 CPU 真正访问时，大概率已经命中缓存了。

4. 指令预取

指令预取和数据的道理一样，只不过预取的是代码。CPU 内部有 分支预测器 和 指令预取器，它们会猜测接下来要执行哪条指令，提前从内存里取出来。

但这里有个坑：分支预测失败。如果 CPU 猜错了，预取的指令就白费了，还得重新取正确的指令，这就是所谓的 流水线冲刷（Pipeline Flush）。

4.1 如何帮助指令预取

作为程序员，我们能做的是：

• 减少分支：能用查表法就别用 if-else
• 让分支可预测：比如把大概率走的分支放在 if 里，小概率走的分支放在 else 里
• 使用 __builtin_expect：告诉编译器哪个分支更可能执行

// 告诉编译器：likely 条件更可能成立
#define likely(x)   __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect(!!(x), 0)

int process_data(int *data, int len) {
    int sum = 0;
    for (int i = 0; i < len; i++) {
        if (likely(data[i] > 0)) {  // 大部分数据都是正数
            sum += data[i];
        } else {
            sum -= data[i];  // 负数的情况很少
        }
    }
    return sum;
}

嗯，这里要注意，__builtin_expect 只是给编译器一个提示，最终效果取决于编译器的优化策略。我在 GCC 上测试过，配合 -O2 优化，分支预测准确率能提升 5%~10%。

5. 预取的性能对比

下面这张表是我在实际项目中测出来的数据，供你参考：

6. 总结与建议

预取是个好东西，但用不好就是双刃剑。我总结了几条原则：

1. 先测量，再优化：用 perf 工具看看缓存缺失率，如果缺失率已经很低（比如 <5%），就别折腾预取了。
2. 预取距离要合适：太近没效果，太远浪费带宽。一般取 64~128 字节（1~2 个缓存行）作为预取距离。
3. 不要过度预取：预取指令本身有开销，而且会占用内存带宽。如果预取的数据用不上，反而会拖慢其他线程。
4. 配合循环展开：循环展开 + 预取，效果往往 1+1 > 2。

我记得有一次优化一个视频编解码的模块，里面有个大循环，每次处理一帧数据。我加了预取之后，帧率从 30fps 提升到了 38fps，效果非常明显。但同样的代码放到另一个平台上，反而慢了 5%。所以，预取的效果和硬件平台强相关，一定要在目标平台上测试。

好了，关于预取与预加载，今天就聊到这里。记住：预取不是银弹，但用对了地方，它就是性能优化的利器。

公众号:蓝海资料掘金营，微信deep3321