编译器工程师眼中的好代码（1）：Loop Interchange

编译器工程师眼中的好代码（1）：Loop Interchange

编者按：C/C++代码在编译时，编译器将源码翻译成CPU可识别的指令序列并生成可执行代码，而最终代码的运行效率取决于由编译器生成的可执行代码。在大部分情况下，编写源代码时就已经决定了程序可以在何种程度下被编译器优化。即使对源代码做微小改动也可能会对编译器生成的代码运行效率产生重大影响。因此，源代码的优化可以在一定程度上帮助编译器生成更高效的可执行代码。 本文将以Loop Interchange的场景为例，讲述在编写代码时可以拿到更优性能的书写方式。

1. Loop Interchange 相关基本概念

1.1 访问局部性

访问局部性指的是在计算机科学领域中应用程序在访问内存的时候，倾向于访问内存中较为靠近的值。这种局部性是出现在计算机系统中的一种可预测行为，我们可以利用系统的这种强访问局部性来进行性能优化。访问局部性分为三种基本形式，分别为时间局部性、空间局部性、循序局部性。

而本文主要讲述的Loop Interchange主要是利用了空间局部性。空间局部性指的是，最近引用过的内存位置以及其周边的内存位置容易再次被使用。比较常见于循环中，比如在一个数组中，如果第3个元素在上一个循环中被使用，那么本次循环中极有可能会使用第4个元素；如果本次循环确实使用第4个元素，就是命中上一次迭代所prefetch到的cache数据。

所以对于数组循环运算，可以利用空间局部性这一特征，保证两次相邻循环中对数组元素的访问在内存上是更加靠近的，即循环访问数组中的元素时stride越小，相应的性能可能会有所优化。

那么，数组在内存上是如何存储的呢？

1.2 Row-major 和 Column-major

Row-major 和 Column-major 是两种将多维数组存储在线性存储中的方式。数组的元素在内存中是连续的；Row-major ordering代表行的连续元素在内存中彼此相邻，而Column-major ordering则是代表列的连续元素彼此相邻，如下图所示。

虽然Row和Column的名称看起来像是特指二维数组，但是Row-major和Column-major也可以推广适用于任何维度的数组。

那么在C/C++中，数组是以以上哪种方式存储的呢？

举一个小例子，用cachegrind工具来展示C使用两种不同的访问形式的CPU的cache丢失率对比。

按行访问：

#include int main(){ size_t i,j; const size_t dim = 1024 ; int matrix [dim][dim]; for (i=0;i< dim; i++) for (j=0;j

按列访问：

#include int main(){ size_t i,j; const size_t dim = 1024 ; int matrix [dim][dim]; for (i=0;i< dim; i++){ for (j=0;j

至于其他常用的编程语言，Fortran、MATLAB等则是默认Column-major形式。

1.3 Loop Interchange

Loop Interchange利用系统倾向于访问内存中较为靠近的值的特征以及C/C++ Row-major的特点，通过改变循环嵌套中两个循环之间的执行顺序，增加整体代码空间局部性。此外，它还可以启用其他重要的代码转换，例如，Loop Reordering就是Loop Interchange扩展到两个以上循环被重新排序时的优化。在LLVM中，Loop Interchange需要通过使能-mllvm -enable-loopinterchange选项启用。

2. 优化示例

2.1 基础场景

简单看下面一个矩阵运算的示例：

原始代码：

for(int i = 0; i < 2048; i++) { for(int j = 0; j < 1024; j++) { for(int k = 0; k < 1024; k++) { C[i * 1024 + j] += A[i * 1024 + k] * B[k * 1024 + j]; } } }

试着把jk两层循环进行Loop Interchange之后的代码：

for(int i = 0; i < 2048; i++) { for(int k = 0; k < 1024; k++) { for(int j = 0; j < 1024; j++) { C[i * 1024 + j] += A[i * 1024 + k] * B[k * 1024 + j]; } } }

可以发现，在原始代码中，最内层的k每次迭代，C要访问的数据不变，A每次访问的stride为1，大概率命中cache，但B由于每次访问的stride为1024，几乎每次都会cache miss。Loop Interchange之后，j位于最内层循环，每次迭代时A每次要访问的数据不变，C和B每次访问的stride为1，都会有很大概率命中cache，cache命中率大大增加。

那么cache命中率是否真的增加，以及两者的性能又如何呢？

原始代码：

$ time -p ./a.out

$ sudo perf stat -r 3 -e cache-misses,cache-references,L1-dcache-load-misses,L1-dcache-loads ./a.out

Loop Interchange后的结果如下：

$ time -p ./a.out

$ sudo perf stat -r 3 -e cache-misses,cache-references,L1-dcache-load-misses,L1-dcache-loads ./a.out

两者相比：

L1-dcache-loads的数目差不多，因为要访问的数据总量差不多；

L1-dcache-load-misses所占L1-dcache-loads的比例在进行Loop Interchange代码修改后降低了将近10倍。

同时，性能数据上也能带来接近9.5%的性能提升。

2.2 特殊场景

当然，在实际使用时，并不是所有的场景都是如2.1中所示的那种工整的可Loop Interchange场景。

for ( int i = 0; i < N; ++ i ) { if( I[i] != 1 ) continue; for ( int m = 0; m < M; ++ m ) { Res2 = res[m][i] * res[m][i]; norm[m] += Res2; } }

如上述场景，如果N是超大数组，那么Loop Interchange理论上可以带来较大收益；但由于两层循环中间增加一个分支判断，导致原本可以Loop Interchange的场景无法实现。

针对这种场景，可以考虑将中间的分支判断逻辑剥离，可以先保证Loop Interchange使得数组res在连续内存上进行访问；至于中间的判断分支逻辑，可以在Loop Interchange两层循环后再进行回退。

for ( int m = 0; m < M; ++ m ) { for ( int i = 0; i < N; ++ i) { Res2 = res[m][i] * res[m][i]; norm[m] += Res2; if( I[i] != 1 ) //补充逻辑，保证源代码语义 { norm[m] -= Res2; continue; } } }

当然，这样的源码修改也需要考虑cost是否值得，如果该if分支进入频率非常高，那么之后回退带来的cost也会较大，可能就需要重新考虑Loop Interchange是否值得；反之，如果分支进入频率非常低，那么Loop Interchange的实现还是可以带来可观的收益的。

3. 毕昇编译器在LLVM社区的贡献

毕昇编译器团队在LLVM社区中对Loop Interchange pass也做出了不小的贡献。团队从legality、profitability等方面对Loop Interchange pass做了全方位的增强，同时也对该pass所支持的场景做了大量的扩展。在Loop Interchange方面，近两年来团队小伙伴为社区提供了二十余个主要的patch，包含Loop Interchange，以及相关的dependence analysis、loop cache analysis、delinearization等分析和优化的增强。简单举几个例子：

D114916 [LoopInterchange] Enable loop interchange with multiple outer loop indvars ( https://reviews.llvm.org/D114916) D114917 [LoopInterchange] Enable loop interchange with multiple inner loop indvars ( Interchange的应用场景扩展到内层或者外层循环中包含不止一个induction variable的情况：

for (c = 0, e = 1; c + e < 150; c++, e++) { d = 5; for (; d; d--) a |= b[d + e][c + 9]; } }

D118073 [IVDescriptor] Get the exact FP instruction that does not allow reordering (https://reviews.llvm.org/D118073) D117450 [LoopInterchange] Support loop interchange with floating point reductions ( Interchange的应用场景扩展到支持浮点类型的reduction计算的场景：

double matrix[dim][dim]; for (j=0;j< dim; j++) for (i=0;i

D120386 [LoopInterchange] Try to achieve the most optimal access pattern after interchange (f(int e[100][100][100], int f[100][100][100]) { for (int a = 0; a < 100; a++) { for (int b = 0; b < 100; b++) { for (int c = 0; c < 100; c++) { f[c][b][a] = e[c][b][a]; } } }`

=>

void f(int e[100][100][100], int f[100][100][100]) { for (int c = 0; c < 100; c++) { for (int b = 0; b < 100; b++) { for (int a = 0; a < 100; a++) { f[c][b][a] = e[c][b][a]; } } } }

D124926 [LoopInterchange] New cost model for loop interchange (

此外，我们还为社区提供了大量的bugfix的patch:

D102300 [LoopInterchange] Check lcssa phis in the inner latch in scenarios of multi-level nested loops D101305 [LoopInterchange] Fix legality for triangular loops D100792 [LoopInterchange] Handle lcssa PHIs with multiple predecessors D98263 [LoopInterchange] fix tightlyNested() in LoopInterchange legality D98475 [LoopInterchange] Fix transformation bugs in loop interchange D102743 [LoopInterchange] Handle movement of reduction phis appropriately during transformation (pr43326 && pr48212) D128877 [LoopCacheAnalysis] Fix a type mismatch bug in cost calculation

以及其他功能的增强：

D115238 [LoopInterchange] Remove a limitation in legality D118102 [LoopInterchange] Detect output dependency of a store instruction with itself D123559 [DA] Refactor with a better API D122776 [NFC][LoopCacheAnalysis] Add a motivating test case for improved loop cache analysis cost calculation D124984 [NFC][LoopCacheAnalysis] Update test cases to make sure the outputs follow the right order D124725 [NFC][LoopCacheAnalysis] Use stable_sort() to avoid non-deterministic print output D127342 [TargetTransformInfo] Added an option for the cache line size D124745 [Delinearization] Refactoring of fixed-size array delinearization D122857 [LoopCacheAnalysis] Enable delinearization of fixed sized array

结语

如果想要尽可能的利用Loop Interchange优化，那在书写C/C++代码时，请尽可能保证每个迭代之间对数组或数列的访问stride越小越好；stride越接近1，空间局部性就越高，自然cache命中率也会更高，在性能数据上也可以拿到更理想的收益。另外，由于C/C++的存储方式为Row-major ordering，所以在访问多维数组时，请注意内层循环要为Column才能拿到更小的stride。

参考

[1][2][3][4][5][6][7][8][9]https://en.wikipedia.org/wiki/Locality\_of\_reference

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。