{"id":"bd3ff8ab-f56b-428b-ac7b-15e935b5309b","arxiv_id":"2608.09874","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"An LLM-based evolutionary framework automatically discovered a multi-level prefetcher that beats the prior hand-designed DPC4 champion on held-out traces.","lead":"ArchAgent v2, an AI-driven evolutionary search system, automatically designed a three-level cache prefetcher that outperforms the previous DPC4 champion BertiGO by 0.3% in geometric mean IPC. The result suggests that agentic AI tools can now compete with hand-designed microarchitecture policies in a competition setting.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The headline result rests on unverified hardware-realizability: Table II's L2 Q-value store row is arithmetically inconsistent as printed, and the code needed to audit the LLM-written prefetcher_size() functions is not released.","rationale":"The reader's weakest assumption is the same storage-enforcement issue, and I agree with it. My concrete addition is that Table II's L2 Q-value store row is internally inconsistent in the manuscript itself, which makes the 'manual check' of the final output look unreliable and reinforces the need for an external audit. This does not prove the policy violates the storage budget, but it raises the cost of accepting the headline result without code. The CONDITIONAL verdict remains appropriate: acceptance should be conditioned on releasing an auditable implementation and a corrected, independently verified storage breakdown. A secondary concern is the small 0.3% overall margin over BertiGO and the undisclosed number of final candidates that received full validation on the held-out set; if several were validated and the best was chosen, the margin could be optimistic. The storage issue is more load-bearing because it determines whether the entry is valid at all.","tokens_in":15546,"tokens_out":9344,"duration_ms":88279,"concrete_test":"Release the final evolved prefetcher source and the prefetcher_size() implementations, then run an independent size audit script that recomputes every table in Table II from the actual C++ data structures using the same bit-width masking rules stated in Figure 3. If the audited L2 footprint exceeds 128 KB (or L1D 32 KB / LLC 256 KB), the headline claim fails; if all three fit, the storage concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"ArchAgent v2's central claim—that it beat BertiGO under DPC4 rules—is valid only if the final prefetcher's physical storage is within the competition budgets (32 KB L1D, 128 KB L2, 256 KB LLC). The paper's only enforcement during evolution is an LLM-written prefetcher_size() function per prefetcher, checked manually only on the final output (Section III.A), and the evolved code is not released. The storage table supplied as evidence is not self-consistent: the L2 'Q-Value Store' row lists '5fts. x 18acts. x 16b' as 99.0 KB, but those factors multiply to 180 bytes; reaching 99 KB would require roughly 2,816 entries per feature. If the table has a typo, the manual check missed it; if the real L2 footprint exceeds 128 KB, the comparison against BertiGO is not competition-legal. Because the size function is generated by the same LLM being optimized for IPC and is not externally auditable from the paper, the hardware-realizability constraint—and hence the headline result—is currently unverified.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents ArchAgent v2, an extension of an LLM-based evolutionary search system for hardware prefetcher design. It adds a cascaded search that evolves L1D, L2, and LLC prefetchers in stages and a storage-size feedback loop that rejects candidate policies whose LLM-written prefetcher_size() exceeds DPC4 budgets. Using ChampSim on DPC4 traces, the authors report a 3.8% geometric-mean IPC improvement over the baseline and a 0.3% improvement over BertiGO, with larger gains on low-bandwidth single-core workloads. The paper also profiles one L1D evolution of over 12,000 candidates.","tokens_in":15791,"tokens_out":6391,"duration_ms":60832,"significance":"If the reported results are reproducible, the paper is a significant demonstration that automated evolutionary agents can navigate a multi-level hardware design space and produce a competitive prefetcher under external competition conditions. The comparison against DPC4 baselines, the separate training and validation traces, and the large candidate corpus are strengths, as is the staged cascade methodology. However, the hardware-realizability claim is not yet independently auditable because the code is not released and the storage accounting contains an arithmetic error; these points are load-bearing for the headline result.","major_comments":[{"comment":"The L2 Q-Value Store row in Table II reports '5fts.×18acts.×16b' as 99.0 KB, but those factors multiply to 180 bytes; reproducing 99.0 KB requires an unstated dimension such as roughly 2,816 entries per feature. Since Section III.A makes the LLM-written prefetcher_size() the only per-candidate enforcement of the 128 KB L2 budget, this discrepancy casts doubt on the reported 110.0 KB L2 total and on the competition-legal status of the final design. Please correct the table, state the exact dimensions of every structure, and provide the final prefetcher_size() accounting so the budget can be verified independently.","section":"Section III.A / Table II"},{"comment":"The paper states that prefetcher_size() functions were written by the LLM, kept synchronized by offline LLM judges, and manually checked only on the final output. This means intermediate candidates that under-report their physical storage would not actually be rejected by the budget check, and because no code is released, even the final candidate's sizes cannot be audited from the manuscript. I ask the authors to release the final L1D/L2/LLC prefetcher code and the size-accounting functions, or to provide an independent tabulation of the physical storage for all final components.","section":"Section III.A"},{"comment":"The validation protocol is underspecified. The text says candidates were evolved on reduced-length traces and final selections were validated on the championship evaluation set, but it does not say whether the validation set was ever used to choose among finalists or to influence lineage decisions, nor how many times finalists were evaluated on it. To support the claim of beating BertiGO under DPC4 rules, please specify the selection protocol and, if available, report results on the official DPC4 hidden evaluation set.","section":"Section III.C"},{"comment":"The 0.3% overall improvement over BertiGO is an aggregate of configurations, and the paper does not state the official DPC4 scoring formula or show how the overall geomean is computed. Because the policy loses on multi-core (about -1.5% versus BertiGO) and wins on single-core, the aggregate claim depends on the exact configuration weights. Please state the scoring formula and give per-component and per-workload results for the Overall row.","section":"Section IV.B / Figure 8"}],"minor_comments":[{"comment":"The y-axis label 'Geomean IPC Normalized to Berti@L1D/Pythia@L2' is ambiguous; please specify whether the normalization is the per-workload geomean of IPC ratios or the geomean of normalized IPC values for each configuration.","section":"Figure 8"},{"comment":"The abbreviations '5fts.' and '18acts.' are not defined in the table or text, and the reader cannot map them to concrete C++ types or hardware storage entries; please clarify the notation.","section":"Table II"},{"comment":"The text says 'we see a 3.8% performance uplift ... winning the competition,' but the paper does not cite official DPC4 standings; please provide the official results or clarify that this is the authors' evaluation of their submission.","section":"Section IV.B"},{"comment":"The abstract says '3.8% geometric mean IPC speedup' while Section IV.B says '3.8% performance uplift'; please be consistent about the baseline and about whether 'overall' includes multi-core configurations.","section":"Abstract and Section IV.B"},{"comment":"The captions of Figures 9 and 10 should explicitly state the difference between normalized IPC and harmonic IPC so the two figures are not mistaken for the same metric.","section":"Figures 9 and 10"}],"recommendation":"major_revision","confidential_remarks":"The central issue for the editor is reproducibility. The paper's methodological contribution is interesting and the DPC4 comparison is external, but the hardware-realizability evidence is not yet auditable. If the authors release the prefetcher code and fix the storage accounting, the paper may be acceptable; without that, the main claim cannot be independently verified. I would not reject outright because the flaws appear fixable within the manuscript's scope, but they are load-bearing enough to require a revision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things to know. First, ArchAgent v2 actually does something new: it couples cascaded freeze-and-evolve search with a runtime storage-footprint check, and produces a three-level prefetcher that beats BertiGO by 0.3% geomean IPC and the baseline by 3.8% on DPC4 traces, with a bigger margin in low-bandwidth single-core. The profiling of 12,000 candidates and the lineage analysis are also useful, not filler. Second, the headline result currently rests on a self-reported size-accounting mechanism, and the printed evidence for it has a concrete error. Table II lists the L2 Q-Value Store as 5 features x 18 actions x 16 bits = 99 KB. That product is 180 bytes. So either a multiplier is missing or the table is typo'd; either way, the manual check did not catch it. More importantly, the code is not released, so no one can audit the prefetcher_size() functions for intermediate candidates. The paper says offline LLM judges kept the size functions synchronized and only the final output was manually checked. Since the same LLM is being optimized on IPC and has a direct incentive to report lower sizes, the hardware-realizability constraint is not yet verified.\n\nThat said, the central methodology is sound in outline. They use separate training and validation traces, standard ChampSim/DPC4 setup, and openly admit multi-core search lags. Their comparison to BertiGO is a re-run, not an official championship result, so calling the policy 'winning the competition' overstates the evidence. The gains are modest and the multi-core result is a 1.5% regression, both acknowledged. The paper also correctly concedes that the discovered prefetcher components are mostly known ideas; the novelty is in the search mechanism, not the final design. The citation pattern looks normal, with AlphaEvolve and the original ArchAgent as legitimate direct ancestors.\n\nBottom line: this is a real step, not a stunt. It deserves serious peer review. I would ask the authors to release the evolved code, or at least the final three prefetchers and size functions, fix the storage table, and soften the 'winning' language to 'competitive under DPC4 rules.' If the size audit checks out, the result is credible and worth citing. I'd bring it to reading group.","headline":"A credible, well-scoped demonstration that agentic search can beat a hand-designed prefetcher under DPC4 rules, but the hardware-realizability claim needs code release and a corrected storage table before the result can be fully trusted.","tokens_in":16376,"tokens_out":3244,"would_cite":true,"duration_ms":32062,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"ArchAgent v2 claims that an LLM-driven evolutionary search can automatically design a three-level data prefetcher that outperforms the winning hand-designed DPC4 solution, BertiGO, reporting a 3.8% geometric-mean IPC speedup over baseline…","keywords":["data prefetching","agentic AI","evolutionary search","LLM code generation","cache prefetcher design","hardware-realizability feedback","multi-level cache","DPC4"],"falsifier":"Re-run the L1D evolution with an independent static size auditor that computes each candidate's table sizes from the source code, or run every accepted candidate through a hardware synthesis and area-estimation tool; if any accepted candidate exceeds the 32 KB, 128 KB, or 256 KB budgets, the hardware-realizability feedback loop did not enforce the constraint it claims to enforce.","tokens_in":1887,"feed_emoji":"🖥️","tokens_out":2604,"duration_ms":75884,"temperature":0.7,"pith_summary":"This paper tries to establish that an LLM-driven evolutionary search can scale from single cache-replacement policies to a much harder three-level data prefetching problem, and that it can beat a hand-designed championship winner. It introduces two fixes for scaling: cascaded search, which evolves and freezes prefetchers one cache level at a time, and a hardware-realizability feedback loop, which rejects over-budget designs during evolution. Under the official DPC4 rules the discovered prefetcher achieves a 3.8% geometric mean IPC speedup over the baseline and a 0.3% edge over the prior champion BertiGO, with a larger 4.6% gain on low-bandwidth single-core configurations. The paper also profiles over 12,000 evaluated candidates to show how the agent's improvements arise from compositional architectural changes. If the claims hold, agentic search becomes a practical tool for microarchitecture discovery, with multi-core evolution remaining an open bottleneck.","feed_headline":"AI agent auto-designs CPU prefetcher that beats the champion","feed_subtitle":"Under DPC4 rules it gains 3.8% IPC over baseline and beats the prior champion on low-bandwidth cores.","key_machinery":"Two load-bearing mechanisms carry the argument. The first is a cascaded divide-and-conquer evolutionary search that subdivides the design space by sequentially evolving and freezing prefetchers at L1D, then L2, then LLC, before running global multi-level optimizations; this makes a non-monotonic, combinatorially large search tractable. The second is a hardware-realizability feedback loop built around a per-prefetcher prefetcher_size() function that reports the candidate's storage footprint, with over-budget designs rejected at compile time so the agent receives a negative reward for violating the 32 KB, 128 KB, and 256 KB budgets. The final policy itself is also a mechanism: it uses dynamically scaled prefetch lookahead, bandwidth throttling driven by core and memory signals, and an arbitrator that routes confident prefetches to L1D while diverting speculative ones to lower cache levels.","core_discovery":"The central claim is that a multi-level prefetcher can be discovered automatically, without hand-written architectural intuition, by an evolutionary LLM agent, and that the discovered policy beats the best human-designed policy in a controlled competition setting. The discovered policy combines an enhanced Berti-style L1D engine with global stride tracking, a global delta history table, and a reinforcement-learning arbitrator; an upgraded Pythia-style L2 engine with richer RL features, power-of-two stride actions, sum-pooling confidence thresholds, and bandwidth throttling; and an LLC engine that switches between regular stride generation and irregular history replay based on a sliding-window measure of access chaos. Storage stays within the DPC4 budgets at 31.1 KB for L1D, 110.0 KB for L2, and 230.3 KB for LLC. The authors report a 3.8% geometric mean IPC speedup over the baseline and a 0.3% overall improvement over BertiGO, with the biggest margin in low-bandwidth single-core configurations (4.6% versus 2.6% for BertiGO), at the cost of roughly 1.5% in multi-core performance.","pith_inferences":["Editorial inference: the single-core-first cascade likely explains the multi-core regression, because optimization pressure was weighted toward low-bandwidth single-core as a proxy and multi-core feedback entered only at the final stage; a cascade that front-loads contention-aware workloads might close that gap.","Editorial inference: the storage-budget guarantee depends on the LLM's own size reports, so an independent static analyzer or synthesis-based area estimator would make the realizability claim airtight and would be a natural extension of the method.","Editorial inference: the roughly fifty-percent discard rate among 12,000 candidates, combined with the flat average proposal quality over time, suggests that better mutation and selection priors could cut simulation cost while preserving the rare high-value architectural jumps.","Editorial inference: the same cascade-plus-budget-feedback architecture could generalize to other multi-level or multi-component hardware search problems, such as co-designing cache replacement with prefetching or searching across different cache hierarchy configurations."],"forward_implications":["Automated agentic search can produce competition-winning microarchitecture policies, not just single-component tweaks: the discovered three-level policy beats the prior hand-designed champion in the same evaluation harness.","Cascaded evolution, optimizing and freezing one cache level at a time, is a viable decomposition for multi-level designs where simultaneous search is slow and non-monotonic.","Embedding a storage-budget check into the compile-and-evaluate loop gives LLM optimizers a hard, per-candidate realizability signal, and the same pattern can be reused for any hardware policy with countable state.","The pipeline should improve as the underlying LLMs improve; the authors expect more reasoning and context to yield larger gains more rapidly and with better efficiency.","Multi-core prefetching remains the limiting frontier: the discovered policy loses about 1.5% to BertiGO on multi-core mixes, and simulation latency continues to impede evolution speed."],"supporting_citations":[{"why":"Defines the DPC4 competition rules, budgets, workloads, and configurations that the evaluation is anchored to.","marker":"[6]"},{"why":"Provides the ChampSim trace-based simulator used for all performance evaluations during evolution and validation.","marker":"[13]"},{"why":"Describes the original ArchAgent system that this work extends from single-level replacement policies to multi-level prefetching.","marker":"[16]"},{"why":"Supplies the Berti L1D prefetcher that is both the baseline and the starting point for L1D evolution.","marker":"[26]"},{"why":"Supplies the Pythia L2 prefetcher that is both the baseline and the starting point for L2 evolution.","marker":"[7]"},{"why":"Provides the AlphaEvolve coding agent that generates, mutates, and compiles candidate prefetcher designs in the evolutionary loop.","marker":"[28]"},{"why":"Describes BertiGO, the prior championship-winning hand-designed policy that ArchAgent v2 compares against and claims to beat.","marker":"[37]"}],"fun_headline_variants":["Agent-designed CPU prefetcher beats hand-crafted champ","AI evolves cache prefetcher that outruns DPC4 winner","Auto-designed prefetcher gains 3.8% IPC, tops champion","Evolutionary agent crafts winning three-level prefetcher"],"cache_read_input_tokens":18432,"weakest_assumption_plain":"The storage-budget guarantee rests on the assumption that the prefetcher_size() functions written by the LLM truthfully report physical storage for every candidate, because only the final output was manually checked; if intermediate designs under-report, an over-budget candidate could pass the realizability filter.","fun_headline_variants_meta":{"raw":{"variants":["Agent-designed CPU prefetcher beats hand-crafted champ","AI evolves cache prefetcher that outruns DPC4 winner","Auto-designed prefetcher gains 3.8% IPC, tops champion","Evolutionary agent crafts winning three-level prefetcher"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001271,"raw_usage":{"total_tokens":5280,"prompt_tokens":1102,"completion_tokens":4178,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":718,"completion_tokens_details":{"reasoning_tokens":4105}},"tokens_in":718,"tokens_out":4178,"duration_ms":29436,"temperature":1.0,"reasoning_tokens":4105,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T05:07:11.265216+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Re-run the L1D evolution with an independent static size auditor that computes each candidate's table sizes from the source code, or run every accepted candidate through a hardware synthesis and area-estimation tool; if any accepted candidate exceeds the 32 KB, 128 KB, or 256 KB budgets, the hardware-realizability feedback loop did not enforce the constraint it claims to enforce.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the DPC4 competition rules, budgets, workloads, and configurations that the evaluation is anchored to."},{"cited_title":"Berti: an accurate local-delta data prefetcher,","cited_arxiv_id":null,"evidence_quote":"Supplies the Berti L1D prefetcher that is both the baseline and the starting point for L1D evolution."},{"cited_title":"Pythia: A customizable hardware prefetching framework using online reinforcement learning,","cited_arxiv_id":null,"evidence_quote":"Supplies the Pythia L2 prefetcher that is both the baseline and the starting point for L2 evolution."},{"cited_title":"Pushing the limits of the berti prefetcher,","cited_arxiv_id":null,"evidence_quote":"Describes BertiGO, the prior championship-winning hand-designed policy that ArchAgent v2 compares against and claims to beat."}],"review_version":1}