性能调优实战：CPU绑定、NUMA感知、分支预测优化、循环优化
说实话，性能调优这件事，很多人觉得是玄学。
代码写好了，跑起来就行，干嘛还要折腾什么CPU绑定、NUMA感知？我以前也这么想。直到有一次，我在一个金融交易系统里，发现同样的代码，在不同机器上性能差了30%。查了三天，最后发现是NUMA架构在作怪。嗯，从那以后，我再也不敢忽视这些底层细节了。
今天咱们就聊聊这四个实战方向：CPU绑定、NUMA感知、分支预测优化、循环优化。它们不是孤立的，而是环环相扣的一套方法论。
核心思想：性能调优的本质，是让硬件资源为你所用，而不是跟硬件对着干。
一、CPU绑定：让线程不再流浪
你想想看，一个线程在CPU之间来回切换，会发生什么？
缓存失效。L1、L2缓存里的数据全白费了。每次切到新核，都得重新加载。这就是所谓的「缓存抖动」。
CPU绑定，说白了就是把线程钉死在某个或某几个核心上。这样缓存命中率能大幅提升。
我的习惯：在延迟敏感的服务里，我几乎必做CPU绑定。比如高频交易、游戏服务器、实时音视频处理。不做绑定，延迟抖动会让你崩溃。
Linux下怎么做？核心API是 sched_setaffinity。
#include <sched.h>
#include <pthread.h>
void bind_to_cpu(int cpu_id) {
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(cpu_id, &cpuset);
pthread_t thread = pthread_self();
int ret = pthread_setaffinity_np(thread, sizeof(cpu_set_t), &cpuset);
if (ret != 0) {
// 处理错误
perror("pthread_setaffinity_np");
}
}
// 使用示例
void* worker(void* arg) {
bind_to_cpu(2); // 绑定到CPU 2
// 业务逻辑...
return NULL;
}这里有个坑。我曾经在项目里绑定了CPU 0，结果发现系统中断也跑在CPU 0上，性能反而下降了。后来我学乖了，一般避开CPU 0，留给系统用。
注意：超线程（Hyper-Threading）下，物理核和逻辑核要区分。绑定到同一个物理核的两个逻辑核，其实共享L1/L2缓存，有时候反而有好处。但如果你要隔离，记得用物理核ID。
二、NUMA感知：别让你的数据跨节点旅行
NUMA架构下，内存访问不是平等的。访问本地内存快，访问远端内存慢。差距有多大？我实测过，大概30%-50%的延迟差异。
所以，NUMA感知的核心原则就一句话：让线程访问它所在NUMA节点上的内存。
怎么做到？两个层面：
- 内存分配策略：用
numa_alloc_local或mbind强制分配本地内存。 - 线程放置：把线程绑定到与内存相同的NUMA节点上。
#include <numa.h>
#include <numaif.h>
void* numa_aware_alloc(size_t size) {
void* ptr = NULL;
// 分配在本地节点
ptr = numa_alloc_local(size);
if (ptr == NULL) {
// fallback到普通malloc
ptr = malloc(size);
}
return ptr;
}
// 检查当前线程所在NUMA节点
int get_current_numa_node() {
return numa_node_of_cpu(sched_getcpu());
}我记得有一次优化一个数据库引擎，数据量很大，跨NUMA访问导致性能瓶颈。用了 numactl 工具一测，发现远端访问占比高达40%。后来改成NUMA感知分配，性能直接提升了25%。
避坑指南：我曾经在NUMA系统上用过 malloc 分配大块内存，然后多个线程随机访问。结果性能惨不忍睹。因为 malloc 默认分配在分配线程所在的节点，其他节点访问就是远端。解决方案：用 numa_alloc_onnode 显式指定节点。
三、分支预测优化：让CPU的猜拳游戏少输几次
现代CPU都有分支预测器。它猜对了，流水线顺畅；猜错了，流水线冲刷，十几二十个周期就浪费了。
怎么帮CPU提高猜对率？两个技巧：
- likely/unlikely宏：告诉编译器哪个分支更可能走。
- 减少难以预测的分支：比如用查表代替条件判断。
// 定义likely/unlikely宏
#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 (unlikely(data[i] < 0)) {
// 异常情况，很少发生
handle_error(data[i]);
continue;
}
sum += data[i];
}
return sum;
}你可能会问：这真的有用吗？
有用。我在一个网络包处理模块里，把错误检查路径标记为 unlikely，吞吐量提升了8%。因为CPU的分支预测器更倾向于预测「正常路径」，你给它提示，它就更准。
更狠的招：如果分支完全随机（比如根据数据值做判断），分支预测基本失效。这时候可以考虑用查表法。比如把 if (x > 0) a else b 改成 table[x >> 31]，用位运算代替分支。
四、循环优化：榨干每一滴性能
循环是程序里最热的热点。优化循环，性价比最高。
几个常用手段：
- 循环展开：减少循环控制开销，增加指令级并行。
- 循环向量化：让编译器生成SIMD指令，一次处理多个数据。
- 循环交换：改变嵌套循环的顺序，提高缓存局部性。
// 原始循环
for (int i = 0; i < N; i++) {
a[i] = b[i] + c[i];
}
// 循环展开（4路）
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];
}
// 处理剩余元素
for (int i = N - (N % 4); i < N; i++) {
a[i] = b[i] + c[i];
}展开多少路合适？这取决于CPU的流水线深度和寄存器数量。我一般从4路开始试，然后8路、16路，看性能曲线。不是越多越好，展开太多会导致寄存器溢出，反而变慢。
循环交换的例子：
// 坏：按列访问，缓存不友好
for (int j = 0; j < COLS; j++) {
for (int i = 0; i < ROWS; i++) {
matrix[i][j] = 0;
}
}
// 好：按行访问，缓存友好
for (int i = 0; i < ROWS; i++) {
for (int j = 0; j < COLS; j++) {
matrix[i][j] = 0;
}
}按行访问比按列访问快多少？我测过，在1024x1024的矩阵上，差距能有5-10倍。因为按行访问利用了空间局部性，缓存命中率高。
还有一个容易被忽略的点：循环内的函数调用。如果循环里调了一个小函数，编译器可能无法内联，导致每次循环都有函数调用开销。我建议把热点函数声明为 inline，或者直接手动内联。
注意：循环优化不要过度。我曾经为了追求极致性能，把循环展开到32路，结果代码体积暴增，指令缓存（I-Cache）压力变大，反而更慢了。优化要适度，用profiler说话。
总结一下
这四个方向，其实是一套组合拳：
- CPU绑定：让线程稳定在核心上，缓存不流浪。
- NUMA感知：让数据离线程近，内存访问不跨节点。
- 分支预测优化：帮CPU少猜错，流水线不空转。
- 循环优化：让热点代码跑得更快，指令级并行拉满。
我个人习惯是：先做profiling，找到热点；然后从循环优化入手，因为收益最直接；如果还有瓶颈，再看CPU绑定和NUMA；分支预测优化是锦上添花，但有时候能带来意外惊喜。
记住一句话：不要相信直觉，相信数据。每次优化前后，都要用perf、vtune这些工具验证。我见过太多人凭感觉优化，结果越优化越慢。
好了，这一章的内容就到这里。代码示例都在上面了，建议你动手跑一跑，看看效果。