代码优化论文精读

1.《Should AI Optimize Your Code? A Comparative Study of Current Large Language Models Versus Classical Optimizing Compilers》

论文内容

该论文进行了一个对比研究，将大语言模型和经典优化编译器性能作对比。 比较对象：GPT-4.0、CodeLlama-70B、传统优化编译器 论文的发现：LLM具有胜过现有优化器的潜力，但往往在长代码任务中生成错误的代码。 CodeLlama-70B在两者中最优，2.1倍。 CETUS是最好的优化编译器，1.9倍。

论文贡献

• 对比LLM和传统优化编译器性能，使用实际应用案例
• 介绍了自动化验证AOT生成代码的正确性和性能的机制
• 我们提出了一个并行计算挑战基准测试套件（PCB）v1.0，包括20个用于评估AOTs能 力的用例。

论文思路

LLM和传统编译器的优劣势：

传统编译器有很多挑战和机遇包括静态分析等

大语言模型： 在捕捉语言学意义和理解语义属性的关键方面具有局限。 擅长代码生成、问题修复和代码完善，但无法保证正确性

提出疑问： AI驱动的模型你能否彻底改变我们处理代码优化的方式？ 论文调研了llm表现优劣得不同情境，最后，我们开发了一个评估自动优化工具的环境作对比。

GPT-4.0和CodeLlama-70B比较评估 结果和CETUS, PLUTO, ROSE对比。使用两种prompting策略。

coT策略（Chain of Thought）

Instructing (IP) - “Given the program below, improve its performance using OpenMP”. IP：给定以下程序，使用OpenMP提升它的性能 • CoT - “Given the C program below, think of a way how to optimize its performance using OpenMP” CoT：给定以下程序，思考一种方式如何使用OpenMP优化它的性能

对比

IP指令提供了一个直接而清晰地指令，而CoT方式使得模型将任务分割成多步，允许在生成优化程序版本之前迭代。

• 准备阶段 生成一个新的程序版本，该版本的检测方式允许优化后的程序部分独立运行，并与原始程序捕获的最终状态进行比较。
• 优化阶段 这一阶段给实验部分的两个LLM prompt去获得优化的版本。原始的代码也给这三个编译器，CETUS，PLUTO和ROSE。 这个过程生成了16个程序版本，给五个AOT。两个LLM，两个不同的prompt，每个prompt三个请求，三个优化编译器以及串行程序。 下一阶段执行并验证版本。
• 验证阶段 这一阶段独立执行实验部分的每一个版本。LLM生成版本与原始版本、序列程序版本相比较。

结果分析：

两种prompting方法没有明显差别。 大模型尽管具有潜力，但还无法作为合适的自动优化工具。

2.浙计毕业论文

核心：构建循环代码生成数据集

对复杂循环结构的支持不足

某些循环代码生成工具在处理复杂的循环结构时可能存在困难。例如，涉及非完美/完美循环、复杂循环依赖的情况下，现有工具可能无法生成高效的代码。

缺乏代码丰富性

目前一些循环代码生成工具采用随机抽取的方式或人工构造样本，或者自动标签化的方式。导致生成的代码分步不均匀，只具有其中某一方面的特征。

缺乏对特定硬件平台的优化

循环代码生成工具通常是通用的，无法针对特定的硬件平台进行优化。这可能导致生成的代码在某些特定的硬件环境下性能不佳，无法充分利用硬件资源。

缺乏灵活性和可扩展性

某些循环代码生成工具可能缺乏灵活性和可扩展性，无法适应不同的编程模型、优化目标或应用领域的需求。这可能限制了其在复杂场景下的适用性和可定制性。

四种数据依赖关系

RAW、WAR、WAW、RAR

Eg:

RAW: a[i] = a[i-1] + 1; WAR: a[i] = a[i+1] - 1;

• 第一步是首先生成整个循环代码的调度与边界；
• 第二步是生成读写语句中的数组访问模式；
• 第三步是生成语句间依赖关系。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

depth：depth 参数用于确定循环维度。
nstmts：nstmts 参数用于确定生成代码段中的语句数量，参数值为生成代码中语句数量实际值。 
bounds_index：bounds_index 参数即表示未排序之前的 2d+1 调度的常量维信息，调度具体信息将会在 3.3 节中有关完美循环以及非完美循环部分展开讲解。 
prob_bounds_exist：prob_bounds_exist 表示每次循环的循环边界被指定的概率。该参数值乘 10％为实际指定概率
narrays_per_dim：同一维数组存在的最大数量
bounds_distance：依赖距离最大值 
依赖距离：依赖关系的两端跨越了多少次迭代
bounds_coef：数组下标常量系数
bounds_index：控制生成完美/不完美循环：
narrays_read：读数组的数量
dep_write_exist：写依赖关系存在的概率
ndeps_read：读依赖关系数量

读依赖选择列表不能有自身

循环数据集中的评估特点：

特征均衡性 完美循环与非完美循环 均衡性较好 parity_of_feature = 0.039 循环内、循环间数据依赖： 均衡性较小 0.021 三种数据依赖类型： 均衡性较差 0.312 原因： 1.写依赖不一定存在，读依赖一定存在 2.写依赖最多只能有一条，但读依赖可以有多条

论文贡献：提出了LaPCL数据集。

编译测试：

编译成功率100%，未优化率3.5%

对比测试：

与TinyBench数据集和LoRA数据集相对比。

Parity1 表示完美循环与非完美循环特征均衡性，Parity2 表示循环间、内数据依赖特 征均衡性，Parity3 表示读写依赖特征均衡性

3.《LLM-Vectorizer: LLM-based Verified Loop Vectorizer》

贡献：

1. 评估了LLM的能力
2. 我们描绘了一个全新的基于AI智能体的方法给LLM反馈，挺高建议的质量
3. 我们使用正式的验证技术（即有界翻译验证）来评估在LLVM级别上的转换的正确性。
4. 我们提供了指定区域的优化，这有助于缩放Alive2，以验证和驳斥几乎两倍多的示例。

实验部分

• RQ1: GPT4依靠自身向量化代码能到达怎样的效果
• RQ2：向量化后的代码能否被正式地验证为等价性？
• RQ3：向量化后的代码性能好吗？ TSVC数据集

评估指标：

pass@k指标 随着k增加，pass@k一开始显著上升，后面趋于平稳 说明对于正确向量化的代码，k的影响很小。

遇到的两个问题：

一次性依赖：

• 解决方法：
• 循环分割或分布 不安全提升： 从环体中提升指令并不总是一个安全的转换。在几个测试中，提升指令更容易矢量化循环，但改变了代码语义。由于依赖性分析较差，llmv转换器执行了几个无法成功修复的不安全。

4.《COMPILER GENERATED FEEDBACK FOR LARGE LANGUAGE MODELS》

编译器为大语言模型生成的反馈

贡献：

1. 给出了3种用于大语言模型的编译器生成反馈模型。
2. 评估了三个带反馈的采样方法。
3. 评估了迭代反馈生成。

三步走：

1. 模型从包含未优化的IR，生成一个优化通过列表、指令计数和优化后的IR自身
2. 在编译器和构建反馈的帮助下从生成中获取可用的指标
3. 给模型提供反馈并给它第二次机会。

• RQ1：反馈模型相比于原始模型在任务优化和任务反馈中的对比如何？
• RQ2：当启用采样的时候，模型如何表现？
• RQ3：我们能否使用反馈模型去迭代生成反馈并且修复现有的解决方案？

快速反馈模型比长反馈更好，猜测原因是因为在输入prompt中使用了生成的IR，引入了噪声，使得模型找到相关的信息。

快速反馈模型未能成功提升原始模型的性能，当大于10个样本时。

这说明或许是快速反馈模型不能懂得如何处理高temperature的生成，或者他总是生成相同的输出。为了减轻这个问题，我们可以生成一个数据集，采样原始模型并且在这些数据上训练快速反馈模型。另一种方法是忽略反馈组件，并为原始模型实现一个更智能的抽样启发式。

future work：

未来的潜在方向可能是通过收集原始模型在给定温度下采样的反馈来训练快速反馈模型。这样，反馈模型就应该更有能力优化更多的模糊代。另一种方法是探索对原始模型的进一步采样，并开发更复杂的算法，以保持多样性而不产生不连贯的文本。