体系结构方向的同学应该都有过这样的经历想复现一篇预取器论文结果光是把 ChampSim 环境配好、把一个预取器跑通就花掉一整周。更让人头疼的是即使你写好了一个预取器也很难判断它到底是真有效还是只在某一条 trace 上碰巧有效。最近两年LLM Agent 开始被尝试用来自动化“设计-实现-验证-调优”这个循环ArchAgent v2 就是这一类工作的代表。本文围绕它展开以 Data Prefetching Championship数据预取冠军赛简称 DPC作为案例完整拆解一个 LLM 驱动的预取器开发闭环。文章适合三类读者一是计算机体系结构方向的学生和研究者想了解 ChampSim 预取器怎么写、怎么评估二是芯片验证与性能优化工程师想看看 LLM Agent 能不能进入自己的日常工具链三是对 LLM Agent 工程化感兴趣的后端开发者想了解“仿真器作为工具”的 Agent 回路设计。读完这篇文章你会掌握预取器开发全流程、ChampSim 核心接口、覆盖率与准确率等关键指标以及如何把编译、仿真、日志解析串成一条自动评估流水线。1. 背景数据预取与 DPC 竞赛1.1 什么是数据预取CPU 的运算速度与内存访问延迟之间的差距一直是体系结构设计里最经典的问题之一。Cache miss 时 CPU 可能要等几百个周期如果能在 CPU 真正需要数据之前把数据提前搬到离 CPU 更近的 Cache 里就能隐藏掉这部分延迟。这个“提前搬数据”的动作就是数据预取Data Prefetching。预取器通常是一个硬件模块它通过观察当前访存流猜测程序的未来访问模式。最简单的思路是“下一行预取”Next-Line即访问了地址 A就把 A 的下一个 Cache Line 也加载进来。复杂一点的预取器会记录每条 load 指令的访问历史判断是否存在固定步长从而做跨步长预取。还有一类预取器不依赖 PC而是根据 Cache 缺失模式、TLB 访问信息或者软件提示来做决策。预取器的难点在于它不是越激进越好。预取了错误的数据会污染 Cache、占用内存带宽甚至比不预取更慢。因此衡量一个预取器不能只看它“有没有抓到未来的数据”还要看它的预取请求有多少是真正被用到的。1.2 Data Prefetching Championship 是什么Data Prefetching Championship 是一个围绕数据预取器设计的体系结构竞赛。竞赛方提供一套统一的仿真平台、一组标准化的访存 trace、一套固定的评测流程参赛者只需要提交自己的预取器实现官方用同一套口径跑分排名。DPC 系列已经办过多届DPC-3 在 2024 年前后公布了最终结果。竞赛的平台是 ChampSim这是一套开源的、基于 trace 驱动的微架构模拟器。ChampSim 模拟了分支预测器、各级 Cache、预取器和内存控制器但不需要像 gem5 那样完整执行指令因此跑起来比全系统模拟器快很多适合大规模对比实验。DPC 与一般论文竞赛最大的区别是它不接受“我觉得有效”的主观论证只看仿真结果。最终排名通常基于多条 trace 上的加权加速比Weighted Speedup。这种“目标函数明确、评估环境固定”的特点使它成为验证自动化设计工具的理想平台。1.3 为什么 DPC 适合作为 Agent 测试场把 DPC 作为 LLM Agent 的“试验场”主要是因为它具备以下几个非常适合自动化迭代的特点。第一目标函数清晰。Agent 不需要理解一堆模糊的定性指标它只需要最大化仿真器输出的 IPC 或加权加速比。第二评估过程完全可复现。同一份代码、同一条 trace、同一个 ChampSim 版本跑出来的结果是确定的Agent 可以放心地根据结果做下一步决策。第三单次评估时间可控。相比跑一个完整操作系统负载ChampSim 的单条 trace 仿真往往在几分钟到几十分钟内完成能够支撑多轮迭代。第四设计空间足够大。预取策略、预取度数、表项大小、触发时机、过滤条件都是可调的这正好是 LLM Agent 擅长探索的搜索空间。换句话说DPC 提供了一个“规则明确、反馈及时”的环境让 Agent 可以把“写代码”和“看结果”这两个动作真正闭环起来。2. ArchAgent v2 与 LLM 驱动的体系结构设计2.1 从 LLM 生成代码到 Architecture Agent如果只是让大语言模型直接输出一段预取器代码结果通常不够可靠。因为 LLM 可能生成一个“看起来很像样”但接口不对、编译不过、或者逻辑有误的实现。传统 Copilot 的使用方式是“人拿到代码后自己验证”而 Agent 的差别在于它把验证环节也接了上来。ArchAgent 这类体系结构 Agent 的核心思路是把 LLM 当作一个能自主工作的研究助理它负责阅读任务描述、检索已有方案、生成候选实现然后调用仿真器执行验证根据仿真结果修改代码。这个循环可以反复执行直到达到目标或者迭代次数耗尽。从公开资料看ArchAgent v1 更多是验证了 LLM 有能力生成结构上合理的硬件设计思路ArchAgent v2 的改进重点通常体现在与仿真工具的更深集成上例如自动解析编译错误、读取仿真日志、把性能指标转成下一轮生成的约束条件。需要注意的是ArchAgent v2 目前仍属于快速演进中的研究型项目不同团队的复现细节并不完全一致本文讨论的是这类 Agent 的通用工作流和工程化要点。2.2 ArchAgent v2 的典型工作流程虽然不同实现细节有差异但一个完整的体系结构设计 Agent 通常遵循下面这个循环任务解析把“为 L2C 编写一个预取器提升 IPC”这类需求拆解成可执行的设计约束。知识检索从论文、历史代码库、预取器模板中检索相关方案作为生成的参考。代码生成基于约束和参考生成一个完整的预取器源文件。工具执行调用编译器编译 ChampSim再调用仿真器运行指定 trace。反馈解析从编译日志和仿真日志中提取报错信息、IPC、覆盖率、准确率等指标。反思与修正根据反馈决定是修 bug、调参数还是换一个完全不同的设计思路。这个循环的精髓在于第 5 步和第 6 步。如果 Agent 只能生成代码却没有办法理解“为什么这轮 IPC 下降了 5%”那它就只是一个代码补全器只有把仿真结果真正转变成下一轮生成的约束它才是一个 Agent。2.3 与 DPC 结合的评估闭环ArchAgent v2 与 DPC 结合本质上就是把 ChampSim 变成一个可调用的“工具函数”。这个工具函数的输入是预取器源码和 trace 路径输出是性能指标。而 DPC 官方提供的 trace 集合则构成了 Agent 的测试集。这种结合带来的好处是Agent 的评估口径与竞赛口径完全一致你不再需要自己发明一套评估方法。Agent 在本地跑出来的 IPC与官方评测环境下的 IPC 具有强相关性。这也是为什么不少体系结构自动化研究选择 DPC 作为基准测试的原因。当然这种闭环也带来了工程上的挑战。最典型的就是环境一致性Agent 修改了代码后能否保证每次都在同一套环境、同一套配置下编译运行如果不能Agent 拿到的反馈就是有噪声的迭代方向也会被带偏。因此一个稳定的评估流水线比 Agent 本身的聪明程度更重要。3. 环境准备ChampSim 与 trace3.1 环境要求在开始之前先确认你的机器满足以下条件操作系统推荐 Ubuntu 20.04 或更高版本的 Linux 环境。编译工具链g 8 以上make以及 CMake部分新版分支需要。Python 3用于编写日志解析脚本。磁盘空间ChampSim 源码很小但 trace 文件通常有几 GB 甚至几十 GB建议预留至少 50GB。内存16GB 以上更稳妥ChampSim 本身不算吃内存但解析大 trace 和保存日志会消耗资源。版本需要根据你的项目实际情况调整。ChampSim 主仓库在不同年份经历了多次重构接口和编译方式都有变化下面以常见环境为例重点演示配置思路。实际操作时请以你 clone 的仓库 README 为准。3.2 拉取并编译 ChampSim拉取仓库很简单git clone https://github.com/ChampSim/ChampSim.git cd ChampSim经典的 ChampSim 版本使用一个配置文件来选择分支预测器和各级缓存的预取器。老版本仓库通常通过config.sh或直接修改配置文件实现编译命令类似于./config.sh make -j8如果你的分支改用了 CMake则类似mkdir build cd build cmake .. make -j8无论哪种方式最终都会生成一个可执行文件一般是bin/champsim。编译成功后可以先运行不带任何参数的执行文件看看它打印的用法说明确认接口格式。3.3 获取 DPC traceDPC 竞赛的 trace 由官方统一发布通常采用 ChampSim 的 trace 格式例如以.champsimtrace.xz结尾的压缩文件。你可以从 DPC 官网或相关社区渠道下载。这里有一个实操建议不要一开始就下载全部 trace。先下载一条中小规模的 trace 用于功能验证等预取器基本工作了再扩展到完整测试集。这样能大幅缩短迭代周期也避免磁盘空间被迅速占满。在 ChampSim 目录下建一个traces/文件夹存放 tracemkdir -p traces mv /path/to/downloaded.trace.xz traces/3.4 运行一次最小 baseline在写任何预取器之前先跑通一次 baseline。你可以先用no预取器配置编译一个最小版本确认整个工具链没有问题。老版本 ChampSim 提供一个run_champsim.sh脚本典型用法类似于./run_champsim.sh bimodal no no no 200000 5000000 traces/601.gcc_s-1850B.champsimtrace.xz参数含义一般是分支预测器、L1D 预取器、L2C 预取器、LLC 预取器、warmup 指令数、simulation 指令数、trace 文件路径。warmup 和 simulation 这两个参数非常关键。warmup 阶段是让模拟器先运行一段指令把 Cache 和分支预测器的状态“预热”起来这个阶段的统计不计入最终结果simulation 阶段才是正式的统计区间。评测口径不统一是很多实验对不上的根源后面会专门讨论。如果执行成功输出日志里会出现类似下面这样的内容CPU 0 cumulative IPC: 1.234不同版本输出的格式略有差异但基本上都能找到 IPC 字段。这一步跑通了就说明环境准备完成。4. 预取器核心原理与性能指标4.1 ChampSim 预取器接口ChampSim 的预取器是以 C 方法的形式嵌入到 Cache 模型中的。不同版本的接口不同下面以 2022 年前后广泛使用的版本为例这段代码片段需要放在预取器源文件中最终与 Cache 类绑定// prefetcher/example.cc #include cache.h void CACHE::prefetcher_initialize() { // 初始化逻辑 } void CACHE::prefetcher_cycle_operate() { // 每个周期可以被调用一次 } uint32_t CACHE::prefetcher_cache_operate( uint64_t addr, uint64_t ip, uint8_t cache_hit, uint8_t type, std::vectoruint64_t prefetched_addr) { // 一次 Cache 访问命中或未命中时被调用 // 把想要预取的地址 push 到 prefetched_addr return prefetched_addr.size(); } uint32_t CACHE::prefetcher_cache_fill( uint64_t addr, uint32_t set, uint32_t way, uint8_t prefetch, uint64_t evicted_addr) { // 一个 Cache Line 被填充时被调用 return 0; } void CACHE::prefetcher_final_stats() { // 仿真结束时的统计输出 }需要提醒的是ChampSim 最新分支可能已经改成了面向对象的Prefetcher类接口。遇到这种情况不要慌直接看仓库里已有的示例预取器文件按它的方式写即可。这四个方法各有用处prefetcher_cache_operate是最核心的入口每次访问 Cache 都会触发通常在这里决定是否发出预取请求。prefetcher_cache_fill在 Cache Line 被填充时触发很多基于事件驱动的预取器在这里更新自己的状态。prefetcher_cycle_operate适合做周期性的后台扫描。prefetcher_initialize和prefetcher_final_stats负责初始化和收尾。type参数表示这次访问的类型可能是 load、store、RFO 等。很多预取器只在 load 类型访问时触发避免为写操作产生过多预取。4.2 Coverage 与 Accuracy预取器有两个绕不开的指标覆盖率Coverage和准确率Accuracy。覆盖率 被预取命中并真正使用的 Cache Miss 数 / 总的 Cache Miss 数。准确率 有用预取次数 / 总预取次数。覆盖率反映“预取器发现了多少本来会发生 miss 的数据”准确率反映“预取器的判断有多准”。这两个指标是矛盾的预取越激进覆盖率通常越高但因为预取了很多没用的地址准确率会下降还可能导致 Cache 污染。实际项目中准确率不足往往比覆盖率不足更致命。因为错误预取不仅浪费内存带宽还会把原本有用的 Cache Line 挤出去造成二次 miss。这也是为什么任何预取器都应该控制预取度数而不是一味地多预取。4.3 从 stdout 解析 IPCAgent 要自动迭代就必须能读懂仿真结果。最简单的方式是用 Python 正则表达式从日志中提取 IPC。下面是一个可用的解析脚本#!/usr/bin/env python3 # 文件路径scripts/parse_ipc.py 从 ChampSim 日志中提取 IPC import re import sys def parse_ipc(log_path: str) - float: with open(log_path, r, encodingutf-8, errorsignore) as f: text f.read() patterns [ rCPU 0 cumulative IPC:\s*([\d.]), rCPU 0 IPC:\s*([\d.]), ] for pattern in patterns: m re.search(pattern, text) if m: return float(m.group(1)) raise RuntimeError(f找不到 IPC 字段请检查日志格式: {log_path}) if __name__ __main__: if len(sys.argv) ! 2: print(用法: python3 parse_ipc.py log_path) sys.exit(1) print(parse_ipc(sys.argv[1]))这个脚本的价值在于把“仿真结果”变成了一个程序可以直接消费的数值。Agent 只需要调用这个脚本就能判断上一轮代码是变好了还是变差了。5. 实战用 Agent 思路从零开发一个预取器5.1 定义任务描述如果使用 LLM Agent 来开发预取器第一步是给 Agent 一个清晰的任务描述。任务描述越具体Agent 生成的代码越接近可用状态。一个建议的任务模板如下你是一名计算机体系结构专家。 请为 ChampSim 实现一个 L2C 数据预取器。 要求 1. 使用 C 实现接口参考仓库中的 prefetcher 示例文件。 2. 预取地址需要对 64B Cache Line 对齐。 3. 不能产生重复的预取请求。 4. 预取度数不超过 4。 5. 目标是在给定 trace 上提升 IPC同时保持较高的预取准确率。 评估方式 编译命令是 make -j8 运行命令是 ./bin/champsim --warmup_instructions200000000 --simulation_instructions500000000 trace。 反馈会以编译错误、IPC、覆盖率、准确率的形式提供。注意任务描述里应该写清楚“接口以仓库示例为准”这类话否则 Agent 很可能会凭训练数据里的知识写出一个接口完全对不上的版本。5.2 第一版Next-Line 预取器先别急着追求复杂算法。Agent 的第一轮生成最好是一个能跑通、能产生 baseline 结果的简单实现。下面是一个 Next-Line 预取器// 文件路径prefetcher/next_line.cc #include cache.h #include iostream namespace { // 每次访问最多生成 1 个预取请求 constexpr uint32_t PREFETCH_DEGREE 1; } void CACHE::prefetcher_initialize() { std::cout Next-Line prefetcher initialized. std::endl; } void CACHE::prefetcher_cycle_operate() { // 本示例不需要周期级操作 } uint32_t CACHE::prefetcher_cache_operate( uint64_t addr, uint64_t ip, uint8_t cache_hit, uint8_t type, std::vectoruint64_t prefetched_addr) { // 地址对齐到 Cache Line 边界 uint64_t base_addr addr ~((1ULL LOG2_BLOCK_SIZE) - 1); for (uint32_t i 1; i PREFETCH_DEGREE; i) { uint64_t pf_addr base_addr (i LOG2_BLOCK_SIZE); prefetched_addr.push_back(pf_addr); } return prefetched_addr.size(); } uint32_t CACHE::prefetcher_cache_fill( uint64_t addr, uint32_t set, uint32_t way, uint8_t prefetch, uint64_t evicted_addr) { return 0; } void CACHE::prefetcher_final_stats() { // 可以在仿真结束时输出统计信息 }这段代码的原理非常简单每次有访存访问时就把当前地址的下一个 Cache Line 的地址加入预取队列。LOG2_BLOCK_SIZE在 ChampSim 中通常定义为 6也就是 64 字节。这个实现虽然简单但它是后续所有迭代的地基。它验证了三件事文件路径正确、接口编译通过、预取器确实能发出请求。5.3 自动评估编译、运行、解析指标有了代码就需要一个自动评估脚本。这个脚本会完成“编译 → 运行 → 解析”三步#!/usr/bin/env bash # 文件路径scripts/eval.sh set -euo pipefail TRACE./traces/601.gcc_s-1850B.champsimtrace.xz WARMUP200000000 SIM500000000 LOGresult.log # 1. 编译。不同版本命令不同按仓库 README 调整。 make -j$(nproc) # 2. 运行仿真。 ./bin/champsim \ --warmup_instructions${WARMUP} \ --simulation_instructions${SIM} \ ${TRACE} 21 | tee ${LOG} # 3. 解析指标。 python3 scripts/parse_ipc.py ${LOG}运行方式chmod x scripts/eval.sh ./scripts/eval.sh在 Agent 的工作流里这个脚本就是那个“工具函数”。Agent 生成代码后调用它然后从 stdout 读到 IPC。如果编译失败编译器报错信息会被捕获并交给 Agent 修正如果编译成功但 IPC 反而下降Agent 也要能理解这个信号并调整策略。5.4 迭代改进Stride 预取器Next-Line 预取器对顺序访问很有效但对固定步长访问比如遍历结构体数组中的某一个字段Next-Line 就无能为力了。下一轮迭代可以让 Agent 实现一个基于 PC 的 Stride 预取器。它记录每条 load 指令上次访问的地址计算出步长然后按这个步长预取后续多个地址。// 文件路径prefetcher/stride.cc #include cache.h #include cstdint #include unordered_map namespace { struct StrideEntry { uint64_t last_addr 0; int64_t stride 0; bool ready false; }; // 以 load PC 为键的表 std::unordered_mapuint64_t, StrideEntry stride_table; // 预取度数控制单次触发最多生成的请求数 constexpr uint32_t PREFETCH_DEGREE 4; } void CACHE::prefetcher_initialize() { std::cout Stride prefetcher initialized. std::endl; } void CACHE::prefetcher_cycle_operate() { } uint32_t CACHE::prefetcher_cache_operate( uint64_t addr, uint64_t ip, uint8_t cache_hit, uint8_t type, std::vectoruint64_t prefetched_addr) { auto it stride_table.find(ip); if (it stride_table.end()) { // 第一次看到这个 PC先记录地址不预取 stride_table[ip] {addr, 0, false}; return 0; } StrideEntry entry it-second; if (entry.ready) { int64_t diff static_castint64_t(addr) - static_castint64_t(entry.last_addr); entry.last_addr addr; // 步长为 0 说明反复访问同一行无需预取 if (diff 0) { return 0; } // 更新步长。如果模式改变就采用最新步长。 if (entry.stride 0) { entry.stride diff; } else if (diff ! entry.stride) { entry.stride diff; } for (uint32_t i 1; i PREFETCH_DEGREE; i) { uint64_t pf_addr static_castuint64_t( static_castint64_t(addr) entry.stride * static_castint64_t(i)); prefetched_addr.push_back(pf_addr); } } else { // 第二次看到这个 PC建立步长基准 entry.last_addr addr; entry.ready true; } return prefetched_addr.size(); } uint32_t CACHE::prefetcher_cache_fill( uint64_t addr, uint32_t set, uint32_t way, uint8_t prefetch, uint64_t evicted_addr) { return 0; } void CACHE::prefetcher_final_stats() { }这个实现有几个工程细节值得说明表用std::unordered_map键是 load 的 PC。不同 load 指令可能拥有不同的步长分开记录能避免互相干扰。前两次访问只用于建立步长基准第三次访问才开始真正预取。这样可以显著减少冷启动时的错误预取。当检测到步长变化时立即采用新步长。这会让预取器对变化的访问模式更敏感。PREFETCH_DEGREE控制了最多生成的请求数。度数越大覆盖率越高但污染风险也越大。如果你的 Agent 是从 Next-Line 迭代到这个版本它应该能观察到在步长访问明显的 trace 上IPC 相比 Next-Line 有提升但在纯顺序访问的 trace 上两者差距可能并不大。5.5 结果对比与结论下面用一个表格概括不同设计的预期表现注意这是定性对比不同 trace 上的具体数值差异很大预取器顺序访问固定步长访问随机访问实现复杂度无预取基线基线基线无Next-Line较好一般差极低Stride较好好差低更复杂策略视实现而定视实现而定通常仍较差高这个对比告诉我们一个重要的道理没有绝对最好的预取器只有最适合某种负载特征的预取器。Agent 的真正价值不是一次性地给出“最终答案”而是能够快速尝试多种策略并告诉你哪些策略在你的 trace 集上值得保留。6. 常见问题与排查思路在实际操作中最容易出问题的往往不是算法本身而是环境与接口。下面整理了一些常见问题问题现象常见原因解决思路编译报错找不到prefetcher_cache_operate定义ChampSim 版本重构接口已变更查看仓库现有 prefetcher 示例文件按新接口实现编译通过但运行时报trace文件打不开trace 路径错误或格式与当前版本不匹配确认 trace 路径检查文件是否完整解压跑完没有任何预取请求产生预取器没有在prefetcher_cache_operate中返回请求数在初始化函数中打印日志确认预取器被加载IPC 反而低于无预取预取准确率太低Cache 被污染减少PREFETCH_DEGREE增加步长确认逻辑同一个 Agent 方案反复失败反馈信息不足Agent 无法判断失败原因把编译日志、仿真日志、IPC 变化完整回传给 Agent本地能跑评测环境跑不了依赖库版本、编译选项不一致统一容器或固定依赖版本记录完整环境信息如果你遇到类似报错可以按下面顺序排查。先看编译阶段。编译错误是最好修的报错信息会直接告诉你哪一行有问题。重点检查函数签名、头文件路径、命名空间。再看运行阶段。运行时报错大多是 trace 路径、参数格式、内存不足。最后看结果阶段。即使跑通了也要先确认 IPC 是否异常再决定是否继续迭代。一个非常实用的技巧是每次修改代码前后都保留完整的编译日志和运行日志。很多 Agent 迭代失败不是因为模型不够聪明而是因为反馈链路太短Agent 看不到中间过程。7. 最佳实践与工程建议7.1 评估协议先行在任何预取器开发之前先固定评估协议。包括固定的 warmup 指令数、固定的 simulation 指令数、固定的一组 trace、固定的 ChampSim 版本。没有固定协议你在不同实验之间看到的 IPC 差异可能来自环境变化而不是预取器本身的改进。例如warmup 过短会让 Cache 处于冷状态统计结果被冷启动效应主导simulation 过短则可能让波动性较大的数据主导结论。建议参考 DPC 官方口径并记录到 README 中。7
LLM Agent驱动预取器开发：基于ChampSim与DPC的实践
体系结构方向的同学应该都有过这样的经历想复现一篇预取器论文结果光是把 ChampSim 环境配好、把一个预取器跑通就花掉一整周。更让人头疼的是即使你写好了一个预取器也很难判断它到底是真有效还是只在某一条 trace 上碰巧有效。最近两年LLM Agent 开始被尝试用来自动化“设计-实现-验证-调优”这个循环ArchAgent v2 就是这一类工作的代表。本文围绕它展开以 Data Prefetching Championship数据预取冠军赛简称 DPC作为案例完整拆解一个 LLM 驱动的预取器开发闭环。文章适合三类读者一是计算机体系结构方向的学生和研究者想了解 ChampSim 预取器怎么写、怎么评估二是芯片验证与性能优化工程师想看看 LLM Agent 能不能进入自己的日常工具链三是对 LLM Agent 工程化感兴趣的后端开发者想了解“仿真器作为工具”的 Agent 回路设计。读完这篇文章你会掌握预取器开发全流程、ChampSim 核心接口、覆盖率与准确率等关键指标以及如何把编译、仿真、日志解析串成一条自动评估流水线。1. 背景数据预取与 DPC 竞赛1.1 什么是数据预取CPU 的运算速度与内存访问延迟之间的差距一直是体系结构设计里最经典的问题之一。Cache miss 时 CPU 可能要等几百个周期如果能在 CPU 真正需要数据之前把数据提前搬到离 CPU 更近的 Cache 里就能隐藏掉这部分延迟。这个“提前搬数据”的动作就是数据预取Data Prefetching。预取器通常是一个硬件模块它通过观察当前访存流猜测程序的未来访问模式。最简单的思路是“下一行预取”Next-Line即访问了地址 A就把 A 的下一个 Cache Line 也加载进来。复杂一点的预取器会记录每条 load 指令的访问历史判断是否存在固定步长从而做跨步长预取。还有一类预取器不依赖 PC而是根据 Cache 缺失模式、TLB 访问信息或者软件提示来做决策。预取器的难点在于它不是越激进越好。预取了错误的数据会污染 Cache、占用内存带宽甚至比不预取更慢。因此衡量一个预取器不能只看它“有没有抓到未来的数据”还要看它的预取请求有多少是真正被用到的。1.2 Data Prefetching Championship 是什么Data Prefetching Championship 是一个围绕数据预取器设计的体系结构竞赛。竞赛方提供一套统一的仿真平台、一组标准化的访存 trace、一套固定的评测流程参赛者只需要提交自己的预取器实现官方用同一套口径跑分排名。DPC 系列已经办过多届DPC-3 在 2024 年前后公布了最终结果。竞赛的平台是 ChampSim这是一套开源的、基于 trace 驱动的微架构模拟器。ChampSim 模拟了分支预测器、各级 Cache、预取器和内存控制器但不需要像 gem5 那样完整执行指令因此跑起来比全系统模拟器快很多适合大规模对比实验。DPC 与一般论文竞赛最大的区别是它不接受“我觉得有效”的主观论证只看仿真结果。最终排名通常基于多条 trace 上的加权加速比Weighted Speedup。这种“目标函数明确、评估环境固定”的特点使它成为验证自动化设计工具的理想平台。1.3 为什么 DPC 适合作为 Agent 测试场把 DPC 作为 LLM Agent 的“试验场”主要是因为它具备以下几个非常适合自动化迭代的特点。第一目标函数清晰。Agent 不需要理解一堆模糊的定性指标它只需要最大化仿真器输出的 IPC 或加权加速比。第二评估过程完全可复现。同一份代码、同一条 trace、同一个 ChampSim 版本跑出来的结果是确定的Agent 可以放心地根据结果做下一步决策。第三单次评估时间可控。相比跑一个完整操作系统负载ChampSim 的单条 trace 仿真往往在几分钟到几十分钟内完成能够支撑多轮迭代。第四设计空间足够大。预取策略、预取度数、表项大小、触发时机、过滤条件都是可调的这正好是 LLM Agent 擅长探索的搜索空间。换句话说DPC 提供了一个“规则明确、反馈及时”的环境让 Agent 可以把“写代码”和“看结果”这两个动作真正闭环起来。2. ArchAgent v2 与 LLM 驱动的体系结构设计2.1 从 LLM 生成代码到 Architecture Agent如果只是让大语言模型直接输出一段预取器代码结果通常不够可靠。因为 LLM 可能生成一个“看起来很像样”但接口不对、编译不过、或者逻辑有误的实现。传统 Copilot 的使用方式是“人拿到代码后自己验证”而 Agent 的差别在于它把验证环节也接了上来。ArchAgent 这类体系结构 Agent 的核心思路是把 LLM 当作一个能自主工作的研究助理它负责阅读任务描述、检索已有方案、生成候选实现然后调用仿真器执行验证根据仿真结果修改代码。这个循环可以反复执行直到达到目标或者迭代次数耗尽。从公开资料看ArchAgent v1 更多是验证了 LLM 有能力生成结构上合理的硬件设计思路ArchAgent v2 的改进重点通常体现在与仿真工具的更深集成上例如自动解析编译错误、读取仿真日志、把性能指标转成下一轮生成的约束条件。需要注意的是ArchAgent v2 目前仍属于快速演进中的研究型项目不同团队的复现细节并不完全一致本文讨论的是这类 Agent 的通用工作流和工程化要点。2.2 ArchAgent v2 的典型工作流程虽然不同实现细节有差异但一个完整的体系结构设计 Agent 通常遵循下面这个循环任务解析把“为 L2C 编写一个预取器提升 IPC”这类需求拆解成可执行的设计约束。知识检索从论文、历史代码库、预取器模板中检索相关方案作为生成的参考。代码生成基于约束和参考生成一个完整的预取器源文件。工具执行调用编译器编译 ChampSim再调用仿真器运行指定 trace。反馈解析从编译日志和仿真日志中提取报错信息、IPC、覆盖率、准确率等指标。反思与修正根据反馈决定是修 bug、调参数还是换一个完全不同的设计思路。这个循环的精髓在于第 5 步和第 6 步。如果 Agent 只能生成代码却没有办法理解“为什么这轮 IPC 下降了 5%”那它就只是一个代码补全器只有把仿真结果真正转变成下一轮生成的约束它才是一个 Agent。2.3 与 DPC 结合的评估闭环ArchAgent v2 与 DPC 结合本质上就是把 ChampSim 变成一个可调用的“工具函数”。这个工具函数的输入是预取器源码和 trace 路径输出是性能指标。而 DPC 官方提供的 trace 集合则构成了 Agent 的测试集。这种结合带来的好处是Agent 的评估口径与竞赛口径完全一致你不再需要自己发明一套评估方法。Agent 在本地跑出来的 IPC与官方评测环境下的 IPC 具有强相关性。这也是为什么不少体系结构自动化研究选择 DPC 作为基准测试的原因。当然这种闭环也带来了工程上的挑战。最典型的就是环境一致性Agent 修改了代码后能否保证每次都在同一套环境、同一套配置下编译运行如果不能Agent 拿到的反馈就是有噪声的迭代方向也会被带偏。因此一个稳定的评估流水线比 Agent 本身的聪明程度更重要。3. 环境准备ChampSim 与 trace3.1 环境要求在开始之前先确认你的机器满足以下条件操作系统推荐 Ubuntu 20.04 或更高版本的 Linux 环境。编译工具链g 8 以上make以及 CMake部分新版分支需要。Python 3用于编写日志解析脚本。磁盘空间ChampSim 源码很小但 trace 文件通常有几 GB 甚至几十 GB建议预留至少 50GB。内存16GB 以上更稳妥ChampSim 本身不算吃内存但解析大 trace 和保存日志会消耗资源。版本需要根据你的项目实际情况调整。ChampSim 主仓库在不同年份经历了多次重构接口和编译方式都有变化下面以常见环境为例重点演示配置思路。实际操作时请以你 clone 的仓库 README 为准。3.2 拉取并编译 ChampSim拉取仓库很简单git clone https://github.com/ChampSim/ChampSim.git cd ChampSim经典的 ChampSim 版本使用一个配置文件来选择分支预测器和各级缓存的预取器。老版本仓库通常通过config.sh或直接修改配置文件实现编译命令类似于./config.sh make -j8如果你的分支改用了 CMake则类似mkdir build cd build cmake .. make -j8无论哪种方式最终都会生成一个可执行文件一般是bin/champsim。编译成功后可以先运行不带任何参数的执行文件看看它打印的用法说明确认接口格式。3.3 获取 DPC traceDPC 竞赛的 trace 由官方统一发布通常采用 ChampSim 的 trace 格式例如以.champsimtrace.xz结尾的压缩文件。你可以从 DPC 官网或相关社区渠道下载。这里有一个实操建议不要一开始就下载全部 trace。先下载一条中小规模的 trace 用于功能验证等预取器基本工作了再扩展到完整测试集。这样能大幅缩短迭代周期也避免磁盘空间被迅速占满。在 ChampSim 目录下建一个traces/文件夹存放 tracemkdir -p traces mv /path/to/downloaded.trace.xz traces/3.4 运行一次最小 baseline在写任何预取器之前先跑通一次 baseline。你可以先用no预取器配置编译一个最小版本确认整个工具链没有问题。老版本 ChampSim 提供一个run_champsim.sh脚本典型用法类似于./run_champsim.sh bimodal no no no 200000 5000000 traces/601.gcc_s-1850B.champsimtrace.xz参数含义一般是分支预测器、L1D 预取器、L2C 预取器、LLC 预取器、warmup 指令数、simulation 指令数、trace 文件路径。warmup 和 simulation 这两个参数非常关键。warmup 阶段是让模拟器先运行一段指令把 Cache 和分支预测器的状态“预热”起来这个阶段的统计不计入最终结果simulation 阶段才是正式的统计区间。评测口径不统一是很多实验对不上的根源后面会专门讨论。如果执行成功输出日志里会出现类似下面这样的内容CPU 0 cumulative IPC: 1.234不同版本输出的格式略有差异但基本上都能找到 IPC 字段。这一步跑通了就说明环境准备完成。4. 预取器核心原理与性能指标4.1 ChampSim 预取器接口ChampSim 的预取器是以 C 方法的形式嵌入到 Cache 模型中的。不同版本的接口不同下面以 2022 年前后广泛使用的版本为例这段代码片段需要放在预取器源文件中最终与 Cache 类绑定// prefetcher/example.cc #include cache.h void CACHE::prefetcher_initialize() { // 初始化逻辑 } void CACHE::prefetcher_cycle_operate() { // 每个周期可以被调用一次 } uint32_t CACHE::prefetcher_cache_operate( uint64_t addr, uint64_t ip, uint8_t cache_hit, uint8_t type, std::vectoruint64_t prefetched_addr) { // 一次 Cache 访问命中或未命中时被调用 // 把想要预取的地址 push 到 prefetched_addr return prefetched_addr.size(); } uint32_t CACHE::prefetcher_cache_fill( uint64_t addr, uint32_t set, uint32_t way, uint8_t prefetch, uint64_t evicted_addr) { // 一个 Cache Line 被填充时被调用 return 0; } void CACHE::prefetcher_final_stats() { // 仿真结束时的统计输出 }需要提醒的是ChampSim 最新分支可能已经改成了面向对象的Prefetcher类接口。遇到这种情况不要慌直接看仓库里已有的示例预取器文件按它的方式写即可。这四个方法各有用处prefetcher_cache_operate是最核心的入口每次访问 Cache 都会触发通常在这里决定是否发出预取请求。prefetcher_cache_fill在 Cache Line 被填充时触发很多基于事件驱动的预取器在这里更新自己的状态。prefetcher_cycle_operate适合做周期性的后台扫描。prefetcher_initialize和prefetcher_final_stats负责初始化和收尾。type参数表示这次访问的类型可能是 load、store、RFO 等。很多预取器只在 load 类型访问时触发避免为写操作产生过多预取。4.2 Coverage 与 Accuracy预取器有两个绕不开的指标覆盖率Coverage和准确率Accuracy。覆盖率 被预取命中并真正使用的 Cache Miss 数 / 总的 Cache Miss 数。准确率 有用预取次数 / 总预取次数。覆盖率反映“预取器发现了多少本来会发生 miss 的数据”准确率反映“预取器的判断有多准”。这两个指标是矛盾的预取越激进覆盖率通常越高但因为预取了很多没用的地址准确率会下降还可能导致 Cache 污染。实际项目中准确率不足往往比覆盖率不足更致命。因为错误预取不仅浪费内存带宽还会把原本有用的 Cache Line 挤出去造成二次 miss。这也是为什么任何预取器都应该控制预取度数而不是一味地多预取。4.3 从 stdout 解析 IPCAgent 要自动迭代就必须能读懂仿真结果。最简单的方式是用 Python 正则表达式从日志中提取 IPC。下面是一个可用的解析脚本#!/usr/bin/env python3 # 文件路径scripts/parse_ipc.py 从 ChampSim 日志中提取 IPC import re import sys def parse_ipc(log_path: str) - float: with open(log_path, r, encodingutf-8, errorsignore) as f: text f.read() patterns [ rCPU 0 cumulative IPC:\s*([\d.]), rCPU 0 IPC:\s*([\d.]), ] for pattern in patterns: m re.search(pattern, text) if m: return float(m.group(1)) raise RuntimeError(f找不到 IPC 字段请检查日志格式: {log_path}) if __name__ __main__: if len(sys.argv) ! 2: print(用法: python3 parse_ipc.py log_path) sys.exit(1) print(parse_ipc(sys.argv[1]))这个脚本的价值在于把“仿真结果”变成了一个程序可以直接消费的数值。Agent 只需要调用这个脚本就能判断上一轮代码是变好了还是变差了。5. 实战用 Agent 思路从零开发一个预取器5.1 定义任务描述如果使用 LLM Agent 来开发预取器第一步是给 Agent 一个清晰的任务描述。任务描述越具体Agent 生成的代码越接近可用状态。一个建议的任务模板如下你是一名计算机体系结构专家。 请为 ChampSim 实现一个 L2C 数据预取器。 要求 1. 使用 C 实现接口参考仓库中的 prefetcher 示例文件。 2. 预取地址需要对 64B Cache Line 对齐。 3. 不能产生重复的预取请求。 4. 预取度数不超过 4。 5. 目标是在给定 trace 上提升 IPC同时保持较高的预取准确率。 评估方式 编译命令是 make -j8 运行命令是 ./bin/champsim --warmup_instructions200000000 --simulation_instructions500000000 trace。 反馈会以编译错误、IPC、覆盖率、准确率的形式提供。注意任务描述里应该写清楚“接口以仓库示例为准”这类话否则 Agent 很可能会凭训练数据里的知识写出一个接口完全对不上的版本。5.2 第一版Next-Line 预取器先别急着追求复杂算法。Agent 的第一轮生成最好是一个能跑通、能产生 baseline 结果的简单实现。下面是一个 Next-Line 预取器// 文件路径prefetcher/next_line.cc #include cache.h #include iostream namespace { // 每次访问最多生成 1 个预取请求 constexpr uint32_t PREFETCH_DEGREE 1; } void CACHE::prefetcher_initialize() { std::cout Next-Line prefetcher initialized. std::endl; } void CACHE::prefetcher_cycle_operate() { // 本示例不需要周期级操作 } uint32_t CACHE::prefetcher_cache_operate( uint64_t addr, uint64_t ip, uint8_t cache_hit, uint8_t type, std::vectoruint64_t prefetched_addr) { // 地址对齐到 Cache Line 边界 uint64_t base_addr addr ~((1ULL LOG2_BLOCK_SIZE) - 1); for (uint32_t i 1; i PREFETCH_DEGREE; i) { uint64_t pf_addr base_addr (i LOG2_BLOCK_SIZE); prefetched_addr.push_back(pf_addr); } return prefetched_addr.size(); } uint32_t CACHE::prefetcher_cache_fill( uint64_t addr, uint32_t set, uint32_t way, uint8_t prefetch, uint64_t evicted_addr) { return 0; } void CACHE::prefetcher_final_stats() { // 可以在仿真结束时输出统计信息 }这段代码的原理非常简单每次有访存访问时就把当前地址的下一个 Cache Line 的地址加入预取队列。LOG2_BLOCK_SIZE在 ChampSim 中通常定义为 6也就是 64 字节。这个实现虽然简单但它是后续所有迭代的地基。它验证了三件事文件路径正确、接口编译通过、预取器确实能发出请求。5.3 自动评估编译、运行、解析指标有了代码就需要一个自动评估脚本。这个脚本会完成“编译 → 运行 → 解析”三步#!/usr/bin/env bash # 文件路径scripts/eval.sh set -euo pipefail TRACE./traces/601.gcc_s-1850B.champsimtrace.xz WARMUP200000000 SIM500000000 LOGresult.log # 1. 编译。不同版本命令不同按仓库 README 调整。 make -j$(nproc) # 2. 运行仿真。 ./bin/champsim \ --warmup_instructions${WARMUP} \ --simulation_instructions${SIM} \ ${TRACE} 21 | tee ${LOG} # 3. 解析指标。 python3 scripts/parse_ipc.py ${LOG}运行方式chmod x scripts/eval.sh ./scripts/eval.sh在 Agent 的工作流里这个脚本就是那个“工具函数”。Agent 生成代码后调用它然后从 stdout 读到 IPC。如果编译失败编译器报错信息会被捕获并交给 Agent 修正如果编译成功但 IPC 反而下降Agent 也要能理解这个信号并调整策略。5.4 迭代改进Stride 预取器Next-Line 预取器对顺序访问很有效但对固定步长访问比如遍历结构体数组中的某一个字段Next-Line 就无能为力了。下一轮迭代可以让 Agent 实现一个基于 PC 的 Stride 预取器。它记录每条 load 指令上次访问的地址计算出步长然后按这个步长预取后续多个地址。// 文件路径prefetcher/stride.cc #include cache.h #include cstdint #include unordered_map namespace { struct StrideEntry { uint64_t last_addr 0; int64_t stride 0; bool ready false; }; // 以 load PC 为键的表 std::unordered_mapuint64_t, StrideEntry stride_table; // 预取度数控制单次触发最多生成的请求数 constexpr uint32_t PREFETCH_DEGREE 4; } void CACHE::prefetcher_initialize() { std::cout Stride prefetcher initialized. std::endl; } void CACHE::prefetcher_cycle_operate() { } uint32_t CACHE::prefetcher_cache_operate( uint64_t addr, uint64_t ip, uint8_t cache_hit, uint8_t type, std::vectoruint64_t prefetched_addr) { auto it stride_table.find(ip); if (it stride_table.end()) { // 第一次看到这个 PC先记录地址不预取 stride_table[ip] {addr, 0, false}; return 0; } StrideEntry entry it-second; if (entry.ready) { int64_t diff static_castint64_t(addr) - static_castint64_t(entry.last_addr); entry.last_addr addr; // 步长为 0 说明反复访问同一行无需预取 if (diff 0) { return 0; } // 更新步长。如果模式改变就采用最新步长。 if (entry.stride 0) { entry.stride diff; } else if (diff ! entry.stride) { entry.stride diff; } for (uint32_t i 1; i PREFETCH_DEGREE; i) { uint64_t pf_addr static_castuint64_t( static_castint64_t(addr) entry.stride * static_castint64_t(i)); prefetched_addr.push_back(pf_addr); } } else { // 第二次看到这个 PC建立步长基准 entry.last_addr addr; entry.ready true; } return prefetched_addr.size(); } uint32_t CACHE::prefetcher_cache_fill( uint64_t addr, uint32_t set, uint32_t way, uint8_t prefetch, uint64_t evicted_addr) { return 0; } void CACHE::prefetcher_final_stats() { }这个实现有几个工程细节值得说明表用std::unordered_map键是 load 的 PC。不同 load 指令可能拥有不同的步长分开记录能避免互相干扰。前两次访问只用于建立步长基准第三次访问才开始真正预取。这样可以显著减少冷启动时的错误预取。当检测到步长变化时立即采用新步长。这会让预取器对变化的访问模式更敏感。PREFETCH_DEGREE控制了最多生成的请求数。度数越大覆盖率越高但污染风险也越大。如果你的 Agent 是从 Next-Line 迭代到这个版本它应该能观察到在步长访问明显的 trace 上IPC 相比 Next-Line 有提升但在纯顺序访问的 trace 上两者差距可能并不大。5.5 结果对比与结论下面用一个表格概括不同设计的预期表现注意这是定性对比不同 trace 上的具体数值差异很大预取器顺序访问固定步长访问随机访问实现复杂度无预取基线基线基线无Next-Line较好一般差极低Stride较好好差低更复杂策略视实现而定视实现而定通常仍较差高这个对比告诉我们一个重要的道理没有绝对最好的预取器只有最适合某种负载特征的预取器。Agent 的真正价值不是一次性地给出“最终答案”而是能够快速尝试多种策略并告诉你哪些策略在你的 trace 集上值得保留。6. 常见问题与排查思路在实际操作中最容易出问题的往往不是算法本身而是环境与接口。下面整理了一些常见问题问题现象常见原因解决思路编译报错找不到prefetcher_cache_operate定义ChampSim 版本重构接口已变更查看仓库现有 prefetcher 示例文件按新接口实现编译通过但运行时报trace文件打不开trace 路径错误或格式与当前版本不匹配确认 trace 路径检查文件是否完整解压跑完没有任何预取请求产生预取器没有在prefetcher_cache_operate中返回请求数在初始化函数中打印日志确认预取器被加载IPC 反而低于无预取预取准确率太低Cache 被污染减少PREFETCH_DEGREE增加步长确认逻辑同一个 Agent 方案反复失败反馈信息不足Agent 无法判断失败原因把编译日志、仿真日志、IPC 变化完整回传给 Agent本地能跑评测环境跑不了依赖库版本、编译选项不一致统一容器或固定依赖版本记录完整环境信息如果你遇到类似报错可以按下面顺序排查。先看编译阶段。编译错误是最好修的报错信息会直接告诉你哪一行有问题。重点检查函数签名、头文件路径、命名空间。再看运行阶段。运行时报错大多是 trace 路径、参数格式、内存不足。最后看结果阶段。即使跑通了也要先确认 IPC 是否异常再决定是否继续迭代。一个非常实用的技巧是每次修改代码前后都保留完整的编译日志和运行日志。很多 Agent 迭代失败不是因为模型不够聪明而是因为反馈链路太短Agent 看不到中间过程。7. 最佳实践与工程建议7.1 评估协议先行在任何预取器开发之前先固定评估协议。包括固定的 warmup 指令数、固定的 simulation 指令数、固定的一组 trace、固定的 ChampSim 版本。没有固定协议你在不同实验之间看到的 IPC 差异可能来自环境变化而不是预取器本身的改进。例如warmup 过短会让 Cache 处于冷状态统计结果被冷启动效应主导simulation 过短则可能让波动性较大的数据主导结论。建议参考 DPC 官方口径并记录到 README 中。7
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
