矩阵转置大概是C++性能优化里最容易被低估的操作。表面上看，它就是一个双重循环把A[i*N+j]搬到B[j*N+i]，代码几行就写完；可一旦矩阵大到超过三级缓存，最简单的实现能慢到你怀疑机器坏了。我前段时间在整理某个数值计算基础库时，顺手把矩阵转置从 4.2 秒优化到了 14 毫秒，加速比超过 300 倍。整个过程没有改算法复杂度，依然是 O(N²)，也没有用到什么超出常识的奇技淫巧，核心只是把内存访问改成 CPU 缓存和向量单元喜欢的形状。这篇文章就是这次调优的完整复盘，从瓶颈分析、工具选型，到一步步落地实现和踩过的坑，都会聊到。

1. 项目定位：矩阵转置为什么会成为性能瓶颈

1.1 从内存访问模型看转置的天然劣势

很多新手觉得矩阵转置是个“计算密集”任务，实际上它几乎不做计算，真正的问题是内存访问模式。现代 CPU 以 64 字节的缓存行（cache line）为单位从 DRAM 读取数据，而你每次只需要 8 字节的 double。如果访问地址是连续的，那一个缓存行里的 8 个 double 都能用上；如果访问地址跨步很大，相当于每取一个数都丢掉同一缓存行里的另外 7 个数，浪费率高达 87.5%。

转置的尴尬就在这里。以行主序存储为例，A[i][j]在内存中是A[i*N+j]，同一行的元素连续，同一列的元素隔着N*8字节。做转置时你要把 A 的列变成 B 的行，无论你怎么写双重循环，总有一端是在跨越式访问。最直观的写法通常是外层循环行、内层循环列：A 侧能连续读，B 侧却每一次写入都跳到不同的内存行。如果 N 很大，比如 8192，那么 B 侧每次写入都要经历一次 cache miss 和 TLB miss，性能直接崩溃。

用一个生活化的类比解释：同样要搬 1000 本书，一种方式是站在书架前顺手把一整排书放进箱子，另一种方式是每拿一本都要跑到隔壁楼层的不同房间。前者是顺序内存访问，后者就是转置朴素实现面对的情况。搬运本身不难，难的是路线设计。

1.2 优化目标与调优思路总览

矩阵转置的优化目标不是减少计算量，而是提高“有效内存带宽利用率”。所谓有效带宽，就是实际读写的数据量除以耗时。我的测试矩阵是 8192×8192 的 double，总共 512 MB 的读数据加 512 MB 的写数据。朴素版本耗时 4.2 秒，算下来有效带宽只有约 0.24 GB/s，这个数字低到几乎等于每次访问都在等内存。优化目标是把它拉到几十 GB/s，因为现代 CPU 的内存带宽通常在这个量级。

调优思路按三个层次展开，优先级是：数据局部性 > 向量位宽 > 线程并行。第一层是缓存分块（blocking），让读写都限制在一小块连续区域内；第二层是 SIMD 向量化，用 256 位寄存器一次处理 4 个 double；第三层是多线程，把互不依赖的块交给多个核并行。顺序不能反：如果先多线程再优化访存，你会收获几个同样慢的线程；如果先 SIMD 但没做分块，向量加载指令照样会频繁掉进 cache miss。

这三板斧叠加后，加速比才可能到百倍以上。单独看每一层，分块带来的收益最大，SIMD 和并行只是在分块打好基础后进一步压榨硬件。

2. 关键技术与工具选型：怎么把优化做得有章法

2.1 性能基准测试的正确姿势

做任何性能优化，第一件事不是写优化代码，而是把“测量环境”搭稳。我见过太多人拿一次循环的运行时间就下结论，结果被 CPU 降频、缓存热身、编译器优化干扰得晕头转向。测量矩阵转置要遵循几条硬规矩。

计时要用std::chrono::steady_clock，不要用system_clock，因为墙钟时间可能被系统时间调整影响。每次测量前先跑几轮热身，让 CPU 频率和缓存状态稳定，再记录多次运行时间取中位数。单次运行的最小值未必可靠，因为可能有其他进程抢占 CPU；中位数能过滤掉这些干扰。

还有一条至关重要：不要让编译器把整个转置优化掉。如果循环结果没有被使用，编译器在-O2以上可能直接删除循环。我通常会在转置后对 B 矩阵整体算一个校验和，再暴露给一个noinline的函数接收，保证所有读写都真实发生。校验和的符号噪声很小，但足以阻止死代码消除。

简单计时框架可以这样写：

#include <chrono> #include <vector> #include <iostream> using Clock = std::chrono::steady_clock; using Ms = std::chrono::duration<double, std::milli>; __attribute__((noinline)) double compute_checksum(const std::vector<double>& m) { double sum = 0; for (size_t i = 0; i < m.size(); ++i) sum += m[i]; return sum; } template <typename F> double bench(int repeat, F&& fn, double& result) { double best = 1e100; for (int r = 0; r < repeat; ++r) { auto t0 = Clock::now(); fn(); auto t1 = Clock::now(); double ms = Ms(t1 - t0).count(); if (ms < best) best = ms; } result = compute_checksum(result_ref); return best; }

这段代码里的细节都不复杂，但缺一不可。正式对比时，我还会用 Linux 的perf stat看 cache-misses 和 instructions，后面排查章节会细说。

2.2 缓存分块：为什么块大小取 64

分块的核心思想是：不要让一次循环遍历整行，而是把矩阵切成若干个小方块，每个方块处理完再处理下一个。这样无论读还是写，都在一个小范围内循环，cache 能装下，缓存行的利用率自然上去。

块大小怎么选？我测试了 16、32、64、128、256 几个档位，综合下来 64×64 的 double 块最稳。一个 64×64 的 double tile 是 64×64×8 = 32 KB，刚好接近很多 CPU 的 L1 数据缓存大小；转置时需要同时容纳 A 侧 tile 和 B 侧 tile，两个 tile 加起来 64 KB，也能放进 L2。如果块太小，比如 8×8，cache 命中率高但循环开销和取指占比变大；如果块太大，比如 256×256，单个 tile 达到 512 KB，超出 L2，又回到了大跨步访问的老路。

分块代码的核心写法是四层循环，注意内层循环要保证写侧连续：

constexpr int N = 8192; constexpr int T = 64; void transpose_blocked(const double* A, double* B) { for (int i0 = 0; i0 < N; i0 += T) { for (int j0 = 0; j0 < N; j0 += T) { for (int i = i0; i < i0 + T; ++i) { for (int j = j0; j < j0 + T; ++j) { B[j * N + i] = A[i * N + j]; } } } } }

这段代码里，内层循环j递增时，B 的地址是连续递增的，写侧能完整使用缓存行；A 侧虽然按N的跨度跨行，但跨度限制在 T 行以内，这 T 个缓存行会一直热在 L1/L2 里，等下一次复用。这就是“用空间换局部性”的典型例子。实测这一步直接把 4.2 秒拉到了 140 毫秒左右，提速接近 30 倍。

2.3 SIMD 与编译器的配合

分块解决的是缓存未命中，SIMD 解决的是每条指令处理的数据量。AVX2 的 256 位寄存器能一次装载 4 个 double，如果只做普通循环，一个周期只能搬 8 字节；用上_mm256_loadu_pd和_mm256_storeu_pd，同样一条内存指令能搬 32 字节。对内存带宽受限的任务，这能带来可观的收益。

不过矩阵转置的 SIMD 没有 memcpy 那么简单。你读到的是 A 的连续行片段，要写到 B 的连续位置，必须把 4×4 的小块在寄存器里转置。一个容易理解的写法是先把 4 行的向量加载到栈上临时矩阵，再按列组合成向量写出去：

#include <immintrin.h> void transpose_4x4(const double* A, int lda, double* B, int ldb, int i, int j) { double tmp[4][4]; for (int r = 0; r < 4; ++r) { _mm256_storeu_pd(tmp[r], _mm256_loadu_pd(&A[(i + r) * lda + j])); } for (int r = 0; r < 4; ++r) { __m256d col = _mm256_setr_pd(tmp[0][r], tmp[1][r], tmp[2][r], tmp[3][r]); _mm256_storeu_pd(&B[(j + r) * ldb + i], col); } }

这段代码里，_mm256_loadu_pd一次读 A 的连续 4 个元素，存入临时矩阵；_mm256_setr_pd再把临时矩阵的一列组合成向量，连续写到 B。它比纯手工 shuffle 慢一点，但胜在直观，编译器也有机会优化。想追求极限的人可以研究 4×4 的 in-register transpose，本质就是 unpack 和 permute 的组合。对多数场景，上面这个版本已经够用。

有了分块和 SIMD，耗时从 140 毫秒降到了 40 毫秒左右。要说明的是，SIMD 在这里的收益没有分块那么大，但它把后续多线程优化的基础打好了——每个线程搬运同样数据时，内存指令数更少，争抢也小。

3. 一步步调优：从 4.2 秒到 14 毫秒的完整实操

3.1 基线版本：写在纸上的转置

优化之前，我先写了一个所有人都想得出来的朴素版本：

void transpose_naive(const double* A, double* B) { for (int i = 0; i < N; ++i) { for (int j = 0; j < N; ++j) { B[j * N + i] = A[i * N + j]; } } }

这个版本有两个致命点。第一，写侧B[j*N+i]的地址跨步是 N，每次 j 加 1 就跳 64 KB（N=8192 时），等于每条缓存行只用第一个 8 字节。第二，A 侧虽然连续读，但 B 侧的写 miss 会堵塞写缓冲，最终让整体速度被最慢的组件拖死。

实测结果：4.2 秒。这是在整个转置被校验函数强制保留的前提下测出来的。换算成有效带宽，读 512 MB 加写 512 MB，总共 1 GB 数据，4.2 秒只能跑 0.24 GB/s。这个数字说明问题不在主频，也不在算法，而在存储层次被用得支离破碎。

另外我验证过，如果把外层循环和内层循环交换，同样糟糕：A 侧变成跨步读，B 侧连续写。因为转置的对称性，你无法通过改变循环顺序同时让两侧都连续。必须引入分块。

3.2 第一板斧：循环分块

分块版本上面已经给出。当时真正落地时，我重点调了分块大小 T。T=64 时，单线程耗时约 140 ms；T=32 时约 160 ms；T=128 时约 190 ms；T=256 时明显恶化到 400 ms 以上。T=64 之所以最优，是因为它在“缓存命中率”和“循环管理开销”之间取得了平衡。

为什么 T=128 不好？因为 128×128 的 double tile 是 128 KB，两个 tile 加起来 256 KB，对很多核的 L2 来说已经太大，部分数据会被挤回 L3。虽然比朴素版本好很多，但无法享受 L1/L2 的低延迟。

分块这步最值得说的不是代码本身，而是它的普适性。凡是类似转置、图像旋转、矩阵重排这类“二维数据重排”问题，分块都是第一优先级的优化手段。它不依赖任何硬件平台特性，只要 CPU 有缓存，就一定有效。

3.3 第二板斧：SIMD 与 4×4 块转置

分块之后，朴素循环变成块内循环，接下来考虑 SIMD。我采用的方式是遍历每个 T×T 块，块内再按 4×4 的小块调用上一节写好的transpose_4x4。完整逻辑如下：

void transpose_simd(const double* A, double* B) { for (int i0 = 0; i0 < N; i0 += T) { for (int j0 = 0; j0 < N; j0 += T) { for (int i = i0; i < i0 + T; i += 4) { for (int j = j0; j < j0 + T; j += 4) { transpose_4x4(A, N, B, N, i, j); } } } } }

初看这段代码，你可能觉得多了一层函数调用会让性能变差。实际上编译器在-O2下会把transpose_4x4内联进循环体，栈上的tmp[4][4]也被寄存器重组代替大半，并不会形成实际调用开销。不过有一点需要注意：transpose_4x4里用了_mm256_setr_pd，如果编译器没做好的话，会产生若干次栈读写。想避免这个问题，可以直接在循环体里写手写的 shuffle 版本。但对这次性能目标来说，栈临时矩阵版本已经足够。

SIMD 做完，耗时降到约 40 ms。和纯分块相比再快 3.5 倍。这里的加速来源并不只是“一次处理 4 个双精度数”，更重要的是向量加载/存储指令减少了循环迭代次数，减少了指令前端压力。对于访存密集任务，指令数越少，越不容易撞上带宽瓶颈。

3.4 第三板斧：多线程并行

分块之后，每个 64×64 的 tile 是完全独立的：A 的读区间不重叠，B 的写区间也不重叠。这给多线程提供了天然的并行边界。我用 OpenMP 并行外层 tile 循环：

#pragma omp parallel for collapse(2) schedule(dynamic, 1) for (int i0 = 0; i0 < N; i0 += T) { for (int j0 = 0; j0 < N; j0 += T) { for (int i = i0; i < i0 + T; i += 4) { for (int j = j0; j < j0 + T; j += 4) { transpose_4x4(A, N, B, N, i, j); } } } }

collapse(2)让两个 tile 维度的循环一起并行，避免只有行方向上并行时出现负载不均。schedule(dynamic, 1)让每个线程动态领取一个 tile，这样即使某些 tile 的缓存状态不同，也不会出现一个线程干等。

结果：14 ms。相比 4.2 秒，加速比约 300 倍。需要强调，多线程这步的收益取决于机器物理核数和内存带宽。我用的测试机有 16 个物理核，超过这个线程数后性能不会再涨，因为内存带宽被占满了。再多开线程只会增加调度噪声。

到这里，整个优化链路可以总结成一张对比表：

注意有效带宽的计算包含读和写两边，所以 14 ms 对应 1 GB 数据量，大约是 71 GB/s，这已经比较接近单台服务器内存带宽的上限了。继续优化的空间不大了，除非改用非临时存储指令或调整 NUMA 内存分配策略。

4. 踩坑记录：性能没有按预期翻倍的排查方法

4.1 优化不生效：编译器把循环优化掉了

第一次做矩阵转置调优时，我犯过一个特别蠢的错误：转置之后直接丢弃结果，计时显示 0.1 毫秒，我还以为自己发现了什么魔法。后来才意识到，编译器在较高优化等级下判断这段计算没有副作用，直接把它删了。

此后我设置了一道强校验：对 B 矩阵算校验和，并把校验和返回值暴露给一个noinline外部函数。只要校验和要读 B，转置的实际内存写就必须发生。编译器也可以选择只计算部分元素来伪造结果，但对这种简单双重循环它不会那么做。如果你用-flto全局链接期优化，还需要让校验函数也放在另一个编译单元里，避免跨模块优化把校验也算没了。

4.2 多线程虚假共享和并行负载不均

多线程版开始调的时候，性能只提升到 60 ms 而不是 14 ms。排查后发现有两点。第一，我没有用collapse(2)，而是只并行了外层i0循环，结果每个线程领到的是一整块“横向条带”，写入 B 时相邻线程写到了离得很近的缓存行，出现 false sharing，互相拖累。第二个问题是部分线程先处理完自己的条带后空闲，负载不均衡。

把并行粒度改成单个 tile 并加schedule(dynamic, 1)后，两个问题都消失了。经验是：访存密集任务里，并行粒度一定要大到足以摊销线程调度开销，又要小到让各线程工作量均衡。64×64 的 tile 在这里正好合适。

4.3 内存对齐和分配开销

用std::vector<double>做存储时，如果只要求 8 字节对齐，_mm256_loadu_pd的 unaligned load 虽然能用，但跨缓存行的 load 可能额外加载两次。对转置这种内存吞吐要求极高的任务，我建议直接用aligned_alloc分配 64 字节对齐的缓冲区：

double* A = static_cast<double*>(aligned_alloc(64, N * N * sizeof(double))); double* B = static_cast<double*>(aligned_alloc(64, N * N * sizeof(double)));

注意aligned_alloc要求 size 是对齐值的整数倍，NN8 在 N=8192 时满足。使用后，SIMD load 可以改成_mm256_load_pd，少了跨缓存行拆分的可能。这里还有一个隐患：分配大数组放在函数热路径里会显著影响计时，最好一次性分配好，多次转置复用缓冲。

4.4 用性能计数器识破假优化

只看耗时容易被噪声骗，建议配合perf stat看几个关键指标。我最关注的是cache-misses和instructions。朴素版本跑下来，cache-misses 动辄数亿，IPC 很低；分块版本 cache-misses 下降一两个数量级；SIMD 版 instructions 明显减少；最后一版有效带宽接近硬件上限时，cache-misses 的水平已经不再是核心瓶颈。

一个常见的误区是 CPU 占用率越高越好。多线程转置时，如果内存带宽已经打满，继续加线程只会让 CPU 时间增加而墙钟时间不变。配合perf stat看到带宽瓶颈后，就应该停止加线程，把时间省下来调试别的。

如果让我给这次调优划个重点，我会说：先测量，再动手；块大小优先于所有花哨指令；SIMD 是锦上添花，不是雪中送炭。矩阵转置这类访存密集任务，真正的敌人永远是缓存未命中，不是计算量。

另外，别在小矩阵上验证百倍加速。我实测 1024×1024 的 double 矩阵，优化前后只有十几倍，因为数据总量不到 16 MB，缓存能兜住一大半，本来就不慢。等矩阵大到 4096×4096、8192×8192，让朴素实现把内存访问的丑陋全部暴露出来，优化带来的提速才显得惊人。遇到这种事，记住一句话：内存访问模式对了，剩下都是水到渠成。