← 返回 2026-03-04

ParEVO：通过智能体进化合成面向不规则数据的高性能并行代码 ParEVO: Synthesizing Code for Irregular Data: High-Performance Parallelism through Agentic Evolution

Liu Yang, Zeyu Nie, Andrew Liu, Felix Zou, Deniz Altinbüken, Amir Yazdanbakhsh, Quanquan C. Liu 📅 2026-03-03 👍 3 2026-07-13 08:35
不规则算法 代码生成 图算法 大语言模型 并行计算 进化搜索 高性能计算
arXiv HuggingFace PDF

用智能体进化合成面向不规则并行数据的高性能代码，平均加速106倍

前置知识

工作-跨度 (Work-Span) 模型

并行算法的标准分析模型，将计算分解为总工作量 $W$（所有子任务工作量之和）和最关键路径长度 $S$（理想无限处理器下的执行时间）。理想加速比为 $W/S$。在此模型下，使用工作-偷取 (work-stealing) 调度器能保证期望运行时间接近 $W/P + S$，其中 $P$ 是处理器数。

ParEVO 的核心思路是让 LLM 学会映射到 ParlayLib 这种已经封装了工作-偷取的高层原语，而不是直接写线程原语。理解 Work-Span 是看懂为什么'高层 DSL + 不可变原语'优于'低层线程 + 锁'的关键。

ParlayLib 并行原语

CMU Parlay 组开发的高层并行 C++ 库，提供 functional-style 不可变原语，包括 parlay::sort、parlay::scan（前缀和）、parlay::reduce、parlay::filter、parlay::pack、parlay::sequence、parlay::parallel_for 等。每个原语都封装了底层调度、负载均衡和同步逻辑，使用者只需关心组合语义。

ParEVO 的整个范式建立在 ParlayLib 之上：模型被训练成把自然语言任务映射到这些原语。理解这些原语的不可变语义（map、reduce、scan 是函数式的、不共享可变状态）是看懂为什么 ParEVO 生成的代码'结构上正确'的关键。

不规则并行 (Irregular Parallelism)

与稠密矩阵乘法等'规则并行'相对的并行计算范式，常见于图遍历、稀疏矩阵、自适应网格、不平衡树。核心挑战是每个元素的计算量与数据相关（例如 BFS 中节点度差异巨大），导致运行时才可知，且静态负载均衡失效，必须依赖动态调度和细粒度同步。

ParEVO 明确聚焦不规则并行，这是 LLM 在 HPC 任务中最容易'灾难性失败'的场景。理解这个背景才能理解为什么 ParEVO 选择用高层原语抽象替代手工写原子操作和锁。

LoRA / QLoRA / DPO 微调

LoRA（Low-Rank Adaptation）通过在原始权重旁引入低秩分解 $W + BA$ 来实现参数高效微调，$B \in \mathbb{R}^{d \times r}$、$A \in \mathbb{R}^{r \times k}$，$r$ 远小于 $d$。QLoRA 在此基础上进一步把基座量化到 4-bit 以节省显存。DPO（Direct Preference Optimization）通过偏好对 $(x, y_w, y_l)$ 直接优化策略模型，使偏好对的 log-ratio 之差最大化，避免训练独立 reward 模型。

ParEVO 用 LoRA 微调 DeepSeek-6.7B（$r=8, \alpha=16$），用 QLoRA + DPO 两阶段微调 Qwen3-30B（$r=16, \alpha=32$，第二阶段 $\beta=0.1$、$\eta=5 \times 10^{-6}$）。理解这些技术才知道论文的训练成本与可复现性边界。

MAP-Elites（质量多样性算法）

一种进化算法变种，维护一个由预先定义'特征维度'网格化的归档集。每一格只保留该特征组合下 fitness 最高的个体，从而在搜索中强制保留多样解，避免种群塌缩。

ParEVO 的进化编码代理 (ECA) 用 MAP-Elites 维持多样性，按代码长度、圈复杂度、同步原语频次三维度分桶，每代从 3 个 fitness 最高 + 5 个多样性最优解中抽样，是其'避免单点收敛到危险原子操作'的关键机制。

研究动机

随着 Dennard scaling 的崩溃，单核频率提升停滞，现代软件性能几乎完全依赖并行化（多核 CPU、GPU、分布式集群）。然而并行编程对绝大多数开发者而言学习曲线陡峭，这一困难在不规则数据（稀疏图、不平衡树、非均匀网格）上被进一步放大：静态调度失效、内存访问模式不可预测、动态负载均衡成为必要。尽管成熟库已能支持规则并行（稠密矩阵乘法等），不规则并行仍是 HPC 领域的'大挑战'。当前的大语言模型在 GitHub 顺序 Python/C++ 语料上预训练，对并发编程存在强烈的'顺序偏置'：当被要求把 BFS 并行化时，模型常常只是把代码包进一句朴素的 #pragma omp parallel for，完全忽略 visited 数组的竞争写入；或者引入粗粒度锁，反而比串行版本还慢。Nichols 等人 2024 年的 ParEval 基准已经证明 LLM 能写出框架语法，但在同步语义和竞争条件上系统性地失败。

本文的目标是ParEVO 的目标是构建一个端到端系统，让 LLM 能够为不规则数据合成正确且高性能的并行代码。论文的具体目标包括三层：(1) 数据层面，发布 Parlay-Instruct 语料库（13,820 条任务），通过 Critic-Refine 流水线对每一条候选都执行真实编译和单元测试验证，过滤出性能达标的算法-代码对；(2) 模型层面，发布三个针对 ParlayLib / RPB 语义微调的专用模型（DeepSeek-Parlay 6.7B、Qwen3-Parlay 30B、Gemini-2.5-Parlay），让模型在'概率生成'与'并行原语的严格语义'之间对齐；(3) 推理层面，部署一个进化编码代理 (ECA)，用编译器、动态竞争检测器和性能 profiler 作为'对手式判官'，迭代修复代码的最后一公里问题。

与已有工作不同的是，ParEVO 区别于已有工作的切入角度是把'抽象层级选择'作为核心论点。论文主张不教 LLM 写低层 pthreads 或 OpenMP pragma 这类容易出错又难以组合的原语，而是训练 LLM 映射到 ParlayLib 这种高层并行 DSL：原语本身封装了调度器、强制不可变语义、把并行化问题降级为'局部 token 级转换'，正好对齐 Transformer 的逐 token 预测能力。同时，与 EvoTune、OpenEvolve、AlphaEvolve 等通用进化代码框架相比，ParEVO 首次把'硬件 profiler + sanitizer 数据竞争检测'作为 fitness 信号引入 HPC 领域，绕开 Singh 等人 2024 年指出的'LLM 无法可靠地自我评判并行代码'的陷阱，确定性地把不安全的代码用 fitness=0 滤掉。

核心方法

ParEVO 是一个三阶段流水线：阶段一用 Teacher-Student-Critic 流程合成高质量并行指令数据；阶段二用这些数据对开源基座做 SFT/QLoRA+DPO 两阶段微调；阶段三在推理时用进化搜索代理 ECA 迭代修复代码。整体思路可以理解为：先把 LLM 的'语法-语义'对齐到高层并行原语（用微调实现），再把'最后一公里正确性 + 性能'交给带真实硬件反馈的进化搜索（用 runtime feedback 实现）。方法论上有两个关键设计：(1) 用确定性外部工具（编译器、ThreadSanitizer、性能 profiler）作为 fitness 函数，把'LLM 自审'换成'机器判官'，避免 LLM 自身的顺序偏置影响评判；(2) 用 MAP-Elites 质量多样性算法维持解的分布，把代码长度、圈复杂度、同步原语频次作为多样性维度，防止种群全部塌缩到'安全但慢'的解上。

ParEVO 的核心创新是'抽象-对齐假设'：与其训练 LLM 写低层线程原语（错误率高、组合困难、需要全局状态追踪），不如训练 LLM 把自然语言意图直接映射到 ParlayLib 的高层不可变原语（map、reduce、scan、filter、pack、sort）。这些原语本身数学上可证明是正确的（在 work-stealing 调度下满足 $W/P + O(S)$ 复杂度），并且与 Transformer 的 token 局部预测能力天然契合——并行化的'思维负担'被原语吸收掉了。第二个核心创新是'硬件作为判官'：ECA 的 fitness 直接来自编译是否通过、ThreadSanitizer 是否报错、wall-clock 执行时间是多少，而不是 LLM 互评。这绕开了'LLM 看到自己生成的代码'时的确认偏置，让编译器成为绝对正确性门槛，profiler 成为性能优化信号。第三个创新是明确量化'正确性-性能权衡'（alignment tax）：fine-tuning 把 Pass@1 从 0.42 提到 0.76，但 Speedup 从 21.7× 降到 13.6×，因为模型学会了优先选 parlay::unique 这类安全原语，回避风险更高的原子操作。

方法步骤详情

阶段一 Parlay-Instruct 语料构造：(1) 用 Gemini-3-Pro 作为 Teacher，对 593 个手写 ParlayLib 黄金样例和 20 道 DMOJ 题目应用三种变异算子 $M$：$M_{\text{type}}$（改数据类型如 int→std::string）、$M_{\text{cons}}$（加谓词如'只排序奇数'以触发 filter→sort 组合）、$M_{\text{algo}}$（结构转换如 reduce→scan）；(2) Critic Loop 用真实编译+单元测试 $\text{Compile}(C) \land \text{UnitTest}(C)$ 拒采样，不通过直接丢弃；(3) 性能优化轨迹用 OpenEvolve 在 20 道 DMOJ 图问题上合成 (C_base, C_opt) 配对，要求 C_opt 至少 1.2× 加速于 C_base，speedup label 在 Code A/Code B 位置随机化以去偏；(4) Rust 端用 DMOJ 执行日志聚合，过滤基础设施错误，去重，按通过状态分层。最终产出 13,820 条已验证指令-代码对，13,120 训练 + 700 评测。\n\n阶段二模型微调：(1) DeepSeek-6.7B-base 在单张 RTX 5000 Ada 上做单阶段 SFT，LoRA 作用于 query/value 投影（$r=8, \alpha=16$, FP16, $\eta=2 \times 10^{-4}$）；(2) Qwen3-Coder-30B-A3B-Instruct 在 H200 上做两阶段：阶段一 QLoRA（$r=16, \alpha=32$）覆盖所有 attention + MLP 线性层；阶段二 DPO，$\beta=0.1, \eta=5 \times 10^{-6}$，对通过/失败配对做偏好学习；(3) Gemini-2.5-Pro 利用其长上下文做 C++ 微调。所有模型对齐到 ParlayLib 语义。\n\n阶段三进化编码代理 ECA：(1) 维护一个候选种群，每个候选附带 fitness（编译通过+测试通过+执行时间倒数）和诊断制品（编译日志、竞争检测报告、针对性 refinement 指令）；(2) fitness 函数定义为 $f(x) = 0$ 若编译/测试失败或触发数据竞争，否则 $f(x) = 1/(T(x) + \varepsilon)$；(3) 每代用 $k=3$ 个 fitness top 候选 + $d=5$ 个 MAP-Elites 多样性候选作为下一代的 prompt 上下文，多样性维度包括代码长度、圈复杂度、同步原语频次；(4) 终止时返回 fitness 最高的候选。评估环境：双路 Intel Xeon Platinum 8562Y+ (64 物理核) + 512GB DDR5，所有实验固定 32 线程。

技术新颖性

ParEVO 的技术新颖性主要体现在三方面。第一，'抽象-对齐'的训练范式：以往工作（OMPGPT、AutoParLLM、BabelTower、UniPar）都聚焦于让 LLM 学习 OpenMP pragma 或 CUDA 翻译，把线程同步的状态追踪负担压在 LLM 注意力机制上；ParEVO 是第一个把目标从'低层命令式并行'换成'高层函数式 DSL'的工作，并用实验证明后者在 Pass@1 和 Build@1 上都有数量级提升（见表 1：Gemini-2.5-Parlay Build@1=0.84 vs Gemini-3-Pro 的 0.25）。第二，'硬件判官'式的 fitness 设计：EvoTune、OpenEvolve、AlphaEvolve 等通用进化框架的 fitness 通常是单元测试通过率或数值目标，ParEVO 是第一个把 ThreadSanitizer 动态数据竞争检测作为硬性 fitness=0 过滤的工作，这直接解决了 Singh 等人指出的'LLM 无法可靠自评并行代码'的瓶颈。第三，明确量化'正确性-性能权衡'（alignment tax）：论文用一个精心设计的消融（表 4）证明 fine-tuning 把 Pass@1 从 0.42 提升到 0.76，但 Speedup@1 从 21.7× 降到 13.6×，并把这个权衡解释为模型学会了用安全高层原语替代原子操作，这是其他 HPC-for-LLM 论文没有显式建模的现象。

A representative sample from the training corpus. Each sample includes a natural language instruction, the ground-truth parallel implementation, and an executable unit test used for verification.
Figure 1: A representative sample from the training corpus. Each sample includes a natural language instruction, the ground-truth parallel implementation, and an executable unit test used for verification.
Comparison of Event Generation Strategies. Left: Code A employs a Map-Scan-Write pattern to enable lock-free parallel writing. Right: Code B relies on sequential push back, preventing parallelization and incurring reallocation costs.
Figure 2: Comparison of Event Generation Strategies. Left: Code A employs a Map-Scan-Write pattern to enable lock-free parallel writing. Right: Code B relies on sequential push back, preventing parallelization and incurring reallocation costs.
Overview of the ParEVO Framework. The system integrates human expert context (problem formulation, parallel tooling) with an evolutionary LLM agent. The cycle iteratively refines candidate parallel algorithms through a rigorous evaluation framework (correctness verification, dynamic race detection, and performance profiling), using metrics to guide the selection of the next population via MAP-Elites.
Figure 3: Overview of the ParEVO Framework. The system integrates human expert context (problem formulation, parallel tooling) with an evolutionary LLM agent. The cycle iteratively refines candidate parallel algorithms through a rigorous evaluation framework (correctness verification, dynamic race detection, and performance profiling), using metrics to guide the selection of the next population via MAP-Elites.

实验结果

ParEval 主结果（表 1）显示 ParEVO 系列的微调模型在所有指标上对基座模型和商业模型都有显著优势。Gemini-2.5-Parlay 达到平均 106.87× 加速，Build@1 提升到 0.84（基座 0.25 接近不能用），在高度不规则的图问题上仍然有 13.6× 稳健加速。DeepSeek-Parlay 仅有 6.7B 参数也能达到 16.40× 平均加速，超过 Gemini-3-Pro 的 12.29×，验证了'小模型+领域微调'可以击败大商业模型。Qwen3-Parlay 30B 在 Pass@1 上较弱（0.33 vs Gemini-2.5-Parlay 的 0.33-0.84 区间），但 Speedup 8.63× 仍优于其基座 Qwen3-Coder-30B-Instruct 的 8.61×。OpenMP 模式下（表 5）Gemini-2.5-Parlay 取得 23.84×，略高于 Gemini-3-Pro 的 23.13×，证明微调收益在不同后端都可迁移。Rust/Rayon 模式（表 5）下 Qwen3-Rust 6.10× 也优于基座 5.70×，但绝对值低于 C++ 端。\n\n强扩展实验（Figure 6）显示 ParEVO 生成的 C++ FFT 代码在 64 核上达到 40× 加速（接近线性），Rust Maximal Matching 也接近基线扩展性。Figure 9 展示 ParEVO 的 BFS 实现击败了基线多队列 BFS：ParEVO 提出了 BackForward BFS（一种新的方向优化变体），在 heavy middle levels 上显著减少边检查。\n\n语义对齐实验（Figure 5）展示了一个戏剧性案例：基座 Gemini-2.5-Pro 在 complex 数字排序任务上 Build@1=0（用错 parlay::sort 的比较器签名），微调模型用 sort_inplace + auto 参数实现 Build@1=1、Speedup 17.5×。\n\n进化代理消融（表 3）显示 Gemini-3-Pro + ECA 30 迭代比单次生成（1.00×）得到 2.218× 加速，10 迭代得到 1.498×——证明迭代搜索不是锦上添花而是必要。\n\n关键反例：图 15/16 的最短路径案例展示对齐税——基座模型在冒险的 atomic CAS 实现上偶尔跑到 $1.10 \times 10^{-4}$ s 中位数（最坏 0.0002s），微调模型用 parlay::tabulate 做 $O(N^2)$ 复制后用 std::vector 串行更新，中位数 $2.30 \times 10^{-3}$ s，反而慢 20 倍但更稳定。表 6 凸包案例更糟：DS-Parlay 因为幻觉出 parlay::convex_hull 函数直接 Pass@1=0、Speedup=0，证明 fine-tuning 也会导致'自信幻觉'。

ParEval results (Temperature=0.2). Our fine-tuned models demonstrate orders-of-magnitude improvements in speedup.
Table 1: ParEval results (Temperature=0.2). Our fine-tuned models demonstrate orders-of-magnitude improvements in speedup.
Runtime Comparison: PBBS & RPB at Thread=32, best speedup across test inputs. Baseline code is state-of-the-art human-written code. We also demonstrate the speedup against one thread, labeled Speedup (1T).
Table 2: Runtime Comparison: PBBS & RPB at Thread=32, best speedup across test inputs. Baseline code is state-of-the-art human-written code. We also demonstrate the speedup against one thread, labeled Speedup (1T).
Impact of Evolutionary Refinement (ECA) on Speedup. 30 iterations of ECA yield a 2.2× speedup over the first valid solution.
Table 3: Impact of Evolutionary Refinement (ECA) on Speedup. 30 iterations of ECA yield a 2.2× speedup over the first valid solution.
Performance on Graph Problems. Fine-tuning improves reliability (Pass@1) but favors safer, slightly slower algorithms.
Table 4: Performance on Graph Problems. Fine-tuning improves reliability (Pass@1) but favors safer, slightly slower algorithms.
ParEval Metrics Comparison between Gemini-2.5-Pro and Gemini-2.5-Parlay. (a-c) highlight that fine-tuning significantly improves the model's ability to construct valid ParlayLib code, with substantial gains in build and pass rates as well as improved running time over the base model.
Figure 4: ParEval Metrics Comparison between Gemini-2.5-Pro and Gemini-2.5-Parlay. (a-c) highlight that fine-tuning significantly improves the model's ability to construct valid ParlayLib code, with substantial gains in build and pass rates as well as improved running time over the base model.
Semantic Alignment Example. The base model (top) fails to compile due to incorrect API usage and strict type definitions in the lambda. The fine-tuned model (bottom) correctly identifies sort_inplace and uses auto to handle the complex number types safely.
Figure 5: Semantic Alignment Example. The base model (top) fails to compile due to incorrect API usage and strict type definitions in the lambda. The fine-tuned model (bottom) correctly identifies sort_inplace and uses auto to handle the complex number types safely.
Strong Scaling results. (c) Algorithms like Discrete Fourier Transform show excellent scaling with ParEVO's generated code, reaching nearly 40× speedup on 64 cores.
Figure 6: Strong Scaling results. (c) Algorithms like Discrete Fourier Transform show excellent scaling with ParEVO's generated code, reaching nearly 40× speedup on 64 cores.
Runtime and Scalability comparisons against expert Rust and C++ baselines. ParEVO solutions track or beat the scalability of hand-optimized code. In (m)-(o), BackForward BFS specifically refers to the new BFS algorithm ParEVO generated, which uses a different method than the baseline implementation that uses multiqueue BFS.
Figure 9: Runtime and Scalability comparisons against expert Rust and C++ baselines. ParEVO solutions track or beat the scalability of hand-optimized code. In (m)-(o), BackForward BFS specifically refers to the new BFS algorithm ParEVO generated, which uses a different method than the baseline implementation that uses multiqueue BFS.
Code comparison for Maximal Matching. Left (Baseline): Uses mixed safe/unsafe access (potential aliasing bugs) and collects results using two separate passes (red highlights). Right (ParEVO): Uses consistent raw pointer access to ensure memory visibility, increases block granularity to 16, and uses a single-pass unzip for result collection (green highlights).
Figure 10: Code comparison for Maximal Matching. Left (Baseline): Uses mixed safe/unsafe access (potential aliasing bugs) and collects results using two separate passes (red highlights). Right (ParEVO): Uses consistent raw pointer access to ensure memory visibility, increases block granularity to 16, and uses a single-pass unzip for result collection (green highlights).
Code comparison for Minimum Spanning Forest (MSF). Left (Baseline): Uses standard indexing for the reservation array (incurring bounds checks) and standard unwrap() (incurring branch checks), highlighted in red. Right (ParEVO): Adopts a 'Maximal Unsafe' strategy, converting all data structures to raw pointers. It uses unwrap_unchecked() and pointer arithmetic (.add()) to eliminate all runtime safety checks, highlighted in green.
Figure 11: Code comparison for Minimum Spanning Forest (MSF). Left (Baseline): Uses standard indexing for the reservation array (incurring bounds checks) and standard unwrap() (incurring branch checks), highlighted in red. Right (ParEVO): Adopts a 'Maximal Unsafe' strategy, converting all data structures to raw pointers. It uses unwrap_unchecked() and pointer arithmetic (.add()) to eliminate all runtime safety checks, highlighted in green.
Code comparison for Maximal Independent Set (MIS). Left (Baseline): Uses unsafe standard Vec<u8> (red), causing undefined behavior (data races) during reads and writing via raw pointers. It uses a small block size (20). Right (ParEVO): Uses Vec<AtomicU8> (green) for correct synchronization using Relaxed ordering. It optimizes throughput with a larger block size (256) and employs a zero-copy cast to convert the atomic vector back to a standard vector at the end.
Figure 12: Code comparison for Maximal Independent Set (MIS). Left (Baseline): Uses unsafe standard Vec<u8> (red), causing undefined behavior (data races) during reads and writing via raw pointers. It uses a small block size (20). Right (ParEVO): Uses Vec<AtomicU8> (green) for correct synchronization using Relaxed ordering. It optimizes throughput with a larger block size (256) and employs a zero-copy cast to convert the atomic vector back to a standard vector at the end.
Code comparison for Spanning Forest. Left (Baseline): Performs a fresh allocation for the reservation array on every call (red) and uses checked indexing/unwrapping inside the hot loop. Right (ParEVO): Implements a memory recycling mechanism via rs cache (green) to reuse the large reservation vector across calls. It also employs get_unchecked and AtomicUnionFind to eliminate bounds checking and pointer dereference overheads.
Figure 13: Code comparison for Spanning Forest. Left (Baseline): Performs a fresh allocation for the reservation array on every call (red) and uses checked indexing/unwrapping inside the hot loop. Right (ParEVO): Implements a memory recycling mechanism via rs cache (green) to reuse the large reservation vector across calls. It also employs get_unchecked and AtomicUnionFind to eliminate bounds checking and pointer dereference overheads.
Code comparison for BFS. Left (Baseline): Uses a standard asynchronous approach where every edge relaxation requires a CAS loop and a queue push (red), leading to high contention on scale-free graphs. Right (ParEVO): Implements Direction-Optimizing BFS (Ligra-style). It dynamically switches between 'Push' (Sparse) and 'Pull' (Dense) modes based on the frontier density (green), drastically reducing edge checks during the heavy middle levels of the traversal.
Figure 14: Code comparison for BFS. Left (Baseline): Uses a standard asynchronous approach where every edge relaxation requires a CAS loop and a queue push (red), leading to high contention on scale-free graphs. Right (ParEVO): Implements Direction-Optimizing BFS (Ligra-style). It dynamically switches between 'Push' (Sparse) and 'Pull' (Dense) modes based on the frontier density (green), drastically reducing edge checks during the heavy middle levels of the traversal.
Runtime Histograms for Graph Shortest Path. The fine-tuned model (b) exhibits tighter variance (reliability) but a higher median runtime due to overhead from safety-focused primitives.
Figure 15: Runtime Histograms for Graph Shortest Path. The fine-tuned model (b) exhibits tighter variance (reliability) but a higher median runtime due to overhead from safety-focused primitives.
Code comparison for Shortest Path (Problem 19 in ParEval). Left (Baseline): Effectively uses std::atomic and Compare-and-Swap (CAS) to manage visitation state in parallel, resulting in a significantly faster runtime. Right (Finetuned): Chooses a high-overhead initialization step (copying the adjacency matrix via tabulate) and falls back to sequential logic for the queue update loop (red), causing O(N 2) startup cost and serialization bottlenecks. Nonetheless, it shows heavier abstraction usage.
Figure 16: Code comparison for Shortest Path (Problem 19 in ParEval). Left (Baseline): Effectively uses std::atomic and Compare-and-Swap (CAS) to manage visitation state in parallel, resulting in a significantly faster runtime. Right (Finetuned): Chooses a high-overhead initialization step (copying the adjacency matrix via tabulate) and falls back to sequential logic for the queue update loop (red), causing O(N 2) startup cost and serialization bottlenecks. Nonetheless, it shows heavier abstraction usage.
Runtime Histograms for ParEval Problem 34 (Scan). The fine-tuned model (b) exhibits tighter variance and highly predictable performance compared to the wider distribution of the base model (a).
Figure 17: Runtime Histograms for ParEval Problem 34 (Scan). The fine-tuned model (b) exhibits tighter variance and highly predictable performance compared to the wider distribution of the base model (a).
查看结构化数据
任务指标本文基线提升
ParEval 全套（Parlay 路径） Speedup@1（平均加速比） Gemini-2.5-Parlay 106.87×、DeepSeek-Parlay 16.40×、Qwen3-Parlay 8.63× Gemini-3-Pro 12.29×、GPT-5 Thinking 14.03×、Claude Opus 4.5 0.65× Gemini-2.5-Parlay vs 最佳商业模型提升约 7.6×；DeepSeek-Parlay 6.7B 超过 Gemini-3-Pro 33%；Claude Opus 4.5 完全失败
ParEval 全套（Parlay 路径） Build@1（首次编译通过率） Gemini-2.5-Parlay 0.84、DeepSeek-Parlay 0.79 Gemini-3-Pro 0.25、GPT-5 0.73、Claude Opus 4.5 0.28 Gemini-2.5-Parlay vs Gemini-3-Pro 提升 3.36×（0.25→0.84），证明对 ParlayLib 类型系统的内化
ParEval 全套（Parlay 路径） Pass@1（首次测试通过率） Gemini-2.5-Parlay 0.33、DeepSeek-Parlay 0.35 Gemini-3-Pro 0.23、GPT-5 0.63、Claude Opus 4.5 0.27 微调提升约 1.4-1.5×，但绝对值仍低，提示 alignment tax；GPT-5 的 Pass@1 最高（0.63）但 Speedup 较低
ParEval 全套（OpenMP 路径） Speedup@1 Gemini-2.5-Parlay 23.84× Gemini-3-Pro 23.13×、Qwen3-Coder-30B-Instruct 16.53× 微调模型迁移到 OMP 后端仍有约 3% 提升；绝对值远低于 Parlay 后端
ParEval 全套（Rust/Rayon 路径） Speedup@1 Qwen3-Rust 6.10× Gemini-3-Pro 7.42×、Qwen3-Coder-30B-Instruct 5.70× Qwen3-Rust vs 基座提升约 7%；但 Gemini-3-Pro 在 Rust 上反而最高 7.42×，说明 Rust 域微调收益有限
RPB（Rust PBBS）- Maximal Independent Set Speedup（vs RPB 人工基线） ParEVO (Gemini) 0.938×（1T）/ 4.125× vs BASE RPB 人工基线 1.116×（1T） 比 RPB 人工 unsafe 基线快 4.1×（0.31876s → 0.07728s），通过 Vec<AtomicU8> 替代 unsafe 指针写入、块粒度从 20 提升到 256
RPB - Minimum Spanning Forest (Rust) Speedup（vs RPB 人工基线） ParEVO (Gemini) 21.43×（1T）/ 1.07× vs BASE RPB 人工基线 13.43×（1T） 采用 'Maximal Unsafe' 策略，unwrap_unchecked + 指针算术消除所有 bounds check，加速 7%
RPB - Maximal Matching (Rust) Speedup（vs RPB 人工基线） ParEVO (Gemini) 21.78×（1T）/ 1.04× vs BASE RPB 人工基线 21.72×（1T） 块粒度从 10 提到 16，单遍 unzip 替换双遍 collection，匹配基线
RPB - BFS (Rust) 运行时间（中位数） ParEVO BackForward BFS 17.5s（大规模图） Baseline 多队列 BFS 40s 实现 Ligra 风格方向优化 BFS，动态切换 Push/Pull 模式，heavy middle levels 减少边检查
PBBSBench - Minimum Spanning Forest (C++) Speedup（vs PBBS 人工基线） ParEVO (Gemini) 23.69×（1T）/ 1.06× vs BASE PBBS 人工基线 22.63×（1T） 比 PBBS 专家手写代码快 6%
PBBSBench - Histogram (C++) Speedup（vs PBBS 人工基线） ParEVO (Gemini) 27.59×（1T） PBBS 人工基线 27.59×（1T） 匹配专家性能（持平）
PBBSBench - Plane Sweep (C++) Speedup（vs PBBS 人工基线） ParEVO (Gemini) > 1.81×（1T）/ 2.68× vs BASE PBBS 人工基线 baseline 在 Plane Sweep 任务上实现 2.68× 加速（131.695s → 6.627s）
ParEval - Complex 数字排序 Build@1 / Speedup Build@1=1、Speedup 17.5× Gemini-2.5-Pro Build@1=0（编译失败） 从 0 编译到正确实现，体现 ParlayLib 语义对齐的质变效果
DMOJ 图问题进化消融 Speedup vs 首个通过解 Gemini-3-Pro + ECA 30 迭代 2.218× Gemini-3-Pro 单次生成 1.00× 30 迭代 2.22×、10 迭代 1.50×，证明 ECA 迭代搜索是必要而非可选
ParEval - 强扩展（FFT） 64 核 Speedup Gemini-2.5-Parlay 40× 理想线性 64× 达到 62% 并行效率，复杂同步被 ParlayLib 原语吸收

局限与改进

作者在 §5.2 明确承认三大局限：(1) 架构范围只覆盖共享内存多核，没有涉及分布式内存（MPI/PGAS），而分布式引入了通信延迟和数据划分两类全新优化维度；(2) ECA 用推理时算力换执行时效率——每跑一次要生成多个候选、编译、执行，cost 不可忽略，但作者认为对运行万亿次的 HPC 内核来说是合理摊销；(3) 模型在陌生算法域会出现'自信幻觉'，论文在 Convex Hull 任务上观察到 DS-Parlay 直接调用不存在的 parlay::convex_hull 而失败（表 6 Pass@1=0），未来计划引入形式化验证工具约束语义错误。我自己的观察还包括：(a) 论文只在 64 核以内评估，缺少 NUMA 感知的进一步讨论；(b) Parlay-Instruct 语料主要来自 Gemini-3-Pro 的合成，存在'教师模型偏见'风险——若 Gemini-3-Pro 自身有盲区，ParEVO 也学不到；(c) Gemini-2.5-Parlay 取得 106× 极高平均加速的部分原因是 Pass@1 较低（0.33），相当于'能跑通的任务跑得飞快'，但分布性不如 GPT-5（Pass@1=0.63, Speedup=14×）稳健；(d) Rust/Rayon 端 Qwen3-Rust 6.10× 反而不如 Gemini-3-Pro 7.42×，说明微调未必总带来收益，在目标域训练数据稀薄时反而可能损害基座已有能力。

独立分析的弱点

(1) 绝对通过率仍偏低：Gemini-2.5-Parlay 的 Pass@1=0.33 意味着 67% 任务需要多次重试才能通过。对 HPC 自动化部署而言，这意味着需要更强的验证-重试循环。改进方向：把多轮 ECA 与自一致性投票结合，让模型在内部先 sample 多个候选再选 best-of-N。(2) 对齐税量化但未解决：fine-tuning 把 Pass@1 提了 0.42→0.76 但 Speedup 跌了 21.7×→13.6×，本质是模型学会了'避免 atomic'。改进方向：在 DPO 阶段增加 'atomic-but-correct' 偏好对，引导模型在安全前提下保留原子操作；或专门设计一个'性能探索 prompt'切换模式。(3) 几何算法失败：Convex Hull、Closest Pair 上 DS-Parlay 出现 0/188 的极端分裂，说明语料对这些特殊算法的覆盖不够。改进方向：把 PBBS 全部 60+ 个 benchmark 都加进语料构造循环，并加形式化验证 (Dafny/Coq) 作为额外 fitness 信号。(4) Rust 域收益小：Qwen3-Rust 6.10× 不如 Gemini-3-Pro 7.42×，微调未带来显著优势。改进方向：Rust 端目前主要靠 prompt-injected primitives，应构建专门的 Rust 进化数据集（类似 DMOJ-Rust 大规模执行日志），而不是简单复用 DMOJ C++ 数据的子集。(5) 进化代理只到 30 迭代：表 3 显示 30 迭代 2.22×，但 10→30 迭代的边际收益递减，论文未探讨 50、100 迭代的收敛行为。改进方向：把 ECA 接入 UCB 风格的 bandit 决定何时停止，并探索更智能的 prompt 策略（程序分析-aware 的 mutation）。

未来方向

作者明确指出的方向：(1) 扩展到分布式内存（MPI/PGAS）——把通信延迟和数据划分作为新的 fitness 维度；(2) 集成形式化验证工具（Dafny、Coq 或基于 ACSL 的 Frama-C）约束语义错误，应对几何算法等域的'自信幻觉'；(3) 在更大规模实验（如 256+ 核、跨节点）上验证 NUMA 感知能力。\n\n基于论文成果可延伸的方向：(a) 把 Parlay-Instruct 的'批判家循环'思想推广到其他领域特定 DSL——比如 SQL 查询优化、Verilog 硬件描述、CUDA kernel 模板，验证'高层抽象 + 拒绝采样'是否在所有需要 LLM 学会结构化生成的任务上都能复现数量级提升；(b) 用 ParEVO 的 fitness 信号直接做 RLHF/GRPO 微调——目前 SFT/DPO 用的是静态偏好对，如果把 ECA 的 (C_base, C_opt) 轨迹作为 on-policy rollouts 做 RLOO 训练，可能进一步收紧对齐税；(c) 探索 DPO 之外的对齐算法（KTO、IPO、SimPO）在'安全 vs 性能'权衡下的表现；(d) 把 ThreadSanitizer 反馈作为'显式约束 prompt'注入到 ECA——当 sanitizer 报错时，让 LLM 直接看到 TSan 的 stack trace 摘要，而不是只看 0/1 标签，这能加速修复效率；(e) 探索 MAP-Elites 多样性维度的更细选择，比如按'使用的 ParlayLib 原语组合'分桶，这可能在 ECA 中保留更多探索性候选。

复现评估

可复现性整体较好，论文在多处明确给出训练配置和资源。代码与数据集完全开源：https://github.com/WildAlg/ParEVO 含 Parlay-Instruct artifacts 与代码；微调模型在 HuggingFace 上发布（deepseek-parlay-6.7b、qwen3-30b-sft-stage2-merged、qwen3_rust_dpo_final_merged）。DeepSeek-6.7B 的训练只需单张 RTX 5000 Ada + LoRA（$r=8$）+ FP16，是最容易复现的入口。Qwen3-30B 两阶段微调需要 H200 + QLoRA（$r=16$），中等门槛。Gemini-2.5-Parlay 微调需要 Gemini API access（Google DeepMind 团队内部使用）。评估硬件明确：双路 Xeon Platinum 8562Y+ (64 物理核) + 512GB DDR5 + H200 (仅推理)，所有实验固定 32 线程。数据合成流程中 Gemini-3-Pro 的随机种子未完全公开（OpenEvolve 框架本身有默认设置），reproducibility 的真正瓶颈是：Gemini-3-Pro Teacher 在 20 道 DMOJ 上合成 (C_base, C_opt) 配对的可重复性、ThreadSanitizer 报告在不同 GCC/Clang 版本下的稳定性。复现整体难度：中高——硬件与模型权重可获得，但语料构造的 stochasticity 可能让最终数字有 ±10% 波动。

论文图表

Table 5: Comprehensive ParEval results for commercial and local models. Shaded regions distinguish C++/ParlayLib/OMP models (Green) from Rust/Rayon models (Purple).

扩展版 ParEval 结果表：覆盖 20+ 模型 × Parlay/OpenMP/Rust 三种后端 × Temperature 0.2/0.7 两个设置，每个组合列出 Build@1、Pass@1、Speedup。ParEVO 模型在每种后端都参与对比。

论文的'完整数据附录'，让读者可以验证 ParEVO 在不同后端、不同温度、不同模型规模下的稳定性。Appendix 中 ParEval 后端 0.2/0.7 的设置差异揭示了采样温度对 Pass/Speedup 的非平凡影响。

Table 6: Detailed Geometry Results. The fine-tuned model dominates in Closest Pair but hallucinates APIs in Convex Hull.

几何算法详细对比：Convex Hull — Gemini-2.5-Pro Pass@1=0.45, Speedup=1.43；DS-Parlay Pass@1=0.00, Speedup=0.00（幻觉 parlay::convex_hull）。Closest Pair 2D — Gemini-2.5-Pro Pass@1=0.40, Speedup=74.48；DS-Parlay Pass@1=0.45, Speedup=188.03（最优）。

暴露 fine-tuning 的'自信幻觉'失败模式：DS-Parlay 在 Convex Hull 上 Pass@1=0，因为模型编造了不存在的 parlay::convex_hull 函数。这是论文承认的几何算法弱点，也是未来工作要引入形式化验证的直接动机。