AI is starting to shape architectural mechanisms, workloads, and evaluation. To make sense of it, we need a compact, shared way to preserve enough of that process for other groups to evaluate and build on AI-assisted claims.

At the 53rd ISCA in Raleigh, AI for architecture stopped feeling like a side conversation. In the hallways, the talk kept coming back to one thing. AI is starting to enter the architecture design loop, the repeated process of framing a problem, proposing or editing a design, measuring it, rejecting weak candidates, and deciding what to try next.

In particular, there were two deep-dive workshops coupled with other activities. The MLArchSys workshop added A³, a segment on agentic approaches to architecture, and the full-day Architecture 2.0 workshop focused entirely on agentic design. Both drew well over a hundred people and were standing-room-only by the end. The same shift was visible in the main program, in a plenary panel on research and education in the GenAI era.

The Architecture 2.0 workshops at ISCA 2026.

The MLArchSys workshops at ISCA 2026.

Full rooms on a particular subject matter are undoubtedly a sign of community momentum. The opportunity now is to turn that momentum into a durable engineering practice. That will take shared evidence, reusable tools, and enough agreement for a claim to leave the room where it was born and still be checked, compared, taught, improved, or rejected by someone else. AI is already producing architectural ideas. The question is what must travel with those ideas for them to become engineering knowledge.

Suppose a paper reports an AI-generated memory prefetcher with a 15 percent speedup. The code runs, and the speedup reproduces under the reported setup. But the agent saw some workloads and not others, adapted to simulator feedback, tried many candidates, and picked this one. What, exactly, is the contribution here? The final prefetcher? The speedup? The prompt? The agent? Or the process that connected them?

Once AI chooses workloads, responds to feedback, and selects which candidate to report, the same uncertainty about what counts as the contribution reappears for every such result. As AI gains more influence, we have to decide which evidence should accompany a result, so that another group can tell which part actually holds. This blog post is about the evidence that should accompany them if they are to become engineering knowledge.

The Scale of the Shift

The workshops reflect a broader rise in AI-mediated systems research. A recent cross-stack survey of more than 7,800 arXiv papers found that the annual AI-for-systems publication volume grew roughly 23× from 2017 to 2025, and even faster in hardware and chip design (GenAI for Systems). These categories reach beyond architecture, and not every paper in them runs an adaptive design loop. But where AI adapts to workloads, simulator feedback, or selection criteria, the final artifact can obscure how the result emerged. As this body of work grows, leaving that process implicit makes it harder to compare results or carry a finding from one group to the next.

Figure 1: Annual AI-for-systems publication volume grew about 23× from 2017 to 2025 (a). The hardware and chip-design categories grew roughly 43× and 60×, respectively, compared with 21× for software (b).

Recent SIGARCH posts show the field working this out in public from different angles. Karu Sankaralingam asks whether architecture has reached an AlphaZero moment, with evaluation, not idea generation, as the real bottleneck. Dimitrios Skarlatos argues that agentic co-design is already reshaping the architect’s role and the hardware-software contract. Jeff Dean and David Patterson project a 10,000× future built on compounding gains, one of them AI automating hardware design itself. Together, their arguments point toward a common question about what should count as evidence when AI helps produce a design. Answering it requires being precise about what changes when AI moves from a bounded tool to an actor in the design process.

What Changes With Agentic Design

AI for architecture means using learned or agentic systems to help shape architectural designs and the evidence used to evaluate them, rather than building hardware optimized to run AI workloads. This direction, framed in recent work on the foundations of AI agents for modern computer system design, overlaps with software generation and electronic design automation (EDA), but it is distinct from both. An open-ended architecture agent can influence mechanisms, abstractions, workloads, simulator configurations, and interfaces whose effects propagate through many downstream programs and tools. That reach is what makes both its designs and its decisions worth scrutinizing.

Machine learning has entered architecture before. Perceptron branch predictors, reinforcement-learning memory controllers, learned prefetchers such as Pythia, surrogate models that approximate expensive simulations, and autotuners that automatically search configuration choices all used statistical learning to sharpen a mechanism or search a design space. In much of that work, ML was part of the artifact or a bounded optimizer, while the workloads, evaluator, and rules governing the search were set outside the model. The agentic shift is not a clean break from autotuning. It expands the scope and authority of the adaptive process. When a system can propose or edit mechanisms, call tools, choose workloads, adapt to simulator feedback, and influence which candidate survives, ML is no longer only inside the design. It starts to shape the claim we make about the design.

This concern predates AI. Human researchers explore design spaces, tune systems, and discard candidates, too, and research has always run on authors disclosing what others need to judge the work, backed by a degree of trust. What changes with an agent is how we scale. An adaptive system can make and revise these choices at machine speed across mechanism code, simulator configurations, workloads, tool calls, and selection criteria, often in response to the same evaluator that later supports the claim. The issue is not that a choice made by an AI system is inherently less trustworthy. It is that a large, tool-mediated search collapses into a final mechanism and a score, and the path that produced them disappears unless someone deliberately records it. The end goal is not to eliminate trust, but to keep that part of the methodology visible enough for others to assess the claim.

Gupta and colleagues’ ArchAgent makes this concrete by designing and implementing cache-replacement policies, not just their parameters. Starting from Mockingjay, a prior state-of-the-art policy, ArchAgent generated Policy31 for the single-core SPEC CPU 2006 suite, with a usage-intensity mechanism that its authors could inspect and test feature by feature. It also generated Policy12, which appeared to beat Mockingjay through what the paper calls a simulator escape, a higher score won by exploiting the simulator rather than the architecture. In ChampSim, unsupported bypassing of last-level cache writes was protected only by an assertion that optimized builds removed, so Policy12 looked faster because the bypassed writes vanished rather than being handled correctly.

The same agentic process produced both a genuine mechanism and a broken measurement, and the reported scores alone would not tell a reviewer which was which. The authors, to their full credit, caught the escape through manual inspection and reported it, exactly the kind of evidence future studies should preserve. A fuller record would not have found the bug automatically, but preserving the build configuration, the rejected policy, and the check that disqualified it would let others see why Policy12 failed and reuse that check in the next study.

Figure 2: (Left) Artifact-only review sees a generated design and a reported number. (Right) Design loop-aware review keeps the artifact in view while adding the declared bounds, the evidence and failures, and a record of who could accept or reject the candidate.

ArchAgent also helps show where Karu Sankaralingam’s AlphaZero comparison holds and where architecture departs from it. AlphaZero discovered powerful Go strategies through self-play, but the board and the rules stayed fixed. Only the strategy could change. Depending on its permissions, an architecture agent can influence the strategy, the board, the rules, and the score used to judge it. Benchmarks can become data the agent adapts to, simulators can become environments it acts on through tool calls, metrics can become optimization targets, and interfaces define what actions it can take. That is why the claim must carry a record of the “design loop,” not just the artifact that emerged from it.

What Evidence to Preserve

Architecture papers already describe mechanisms, baselines, workloads, simulators, and evaluation procedures, so this is not a call for longer methods sections. What they rarely preserve is how the search reached the reported design. A compact record would make a few things visible:

• Bounds: what the agent could see and change, and what stayed fixed
• Feedback: how much simulator feedback it drew on, and how it steered the search
• Evidence and failures: what supported the reported result, and which candidates were rejected and why
• The decision: who could reject a candidate, who made the final call, and what would overturn the result

None of it is exotic. It is the part of the process that an adaptive search tends to erase.

Machine learning has already faced a version of this gap. A released model or dataset often lacked sufficient context to assess its intended use, evaluation, or provenance. In response, model cards and datasheets for datasets provided the field with compact records that accompany the artifact, short enough to read yet specific enough to state what the work does and does not support. Architecture needs the same kind of record, extended from a finished artifact to the search that produced it.

The reporting burden should scale with how much authority the agent had. If AI only helped implement a mechanism specified by a human, ordinary artifact disclosure is probably enough. If it chose workloads, edited the design, adapted to simulator feedback, or determined which candidate was reported, some account of that process should accompany the result. A simple test is whether AI materially shaped the mechanism, workload, evaluator, stopping rule, rejection rule, or reported result. That record need not become a universal checklist, expose the model’s private reasoning, or promise an exact replay of a randomized search. Its format should emerge through use and revision rather than being settled in advance. What matters is how much of an AI-shaped process must stay visible for another group to see why a result survived and whether it holds under different assumptions.

Existing practice offers only partial precedents. Declaring the setup before a search resembles preregistration, keeping the evidence trail resembles artifact evaluation, and preserving failed alternatives resembles ablation studies, which test the effect of changing one part of a design, as well as negative result reporting. The individual practices are not new. The change is that a single adaptive system can operate continuously across the design, workload, evaluator, and stopping rule, which are usually documented separately.

A record like this is a good-faith disclosure, not proof. An author can omit an inconveniently rejected candidate, and a reviewer cannot rerun an adaptive search to catch the omission, especially when the agent relies on a proprietary model that shifts over time and never repeats a run exactly. The record cannot stand on its own. What keeps it honest is disclosure scaled to the agent’s authority, read by reviewers rather than filed as a badge, and confirmed against evidence the search did not produce.

A result selected through adaptive evaluation should face at least one confirmation check outside the search, using held-out workloads, a second simulator, or a targeted test of the claimed mechanism. If the same agent tunes against the simulator that scores it, selects its evaluation workloads, and stops once the metric looks good, the evaluator has become part of the optimization loop, the architecture equivalent of training on the test set, or evaluation leakage. The check must also use measurements appropriate to the claim, and as a recent SIGARCH post on full-system timing simulation argues, simulation speed and fidelity are already in tension before an agent begins optimizing. Agent feedback makes the measurement window and metric part of the search surface, so authors should explain why the confirmation is credible and what evidence would overturn the result.

The same shift that put agents into the design loop is now putting them into the review loop. In systems research, agents already drive the design loop end-to-end, and elsewhere they draft and review their own papers, with a language model serving as the judge. An automated judge can share the blind spots of the system it reviews, so it does not replace the independent check. But it does raise the value of a record built to be machine-readable as well as human-readable, one that the next agent can use to rebuild the setup, rerun the disqualifying check, and test the claim rather than take a summary on faith.

A Shared Layer for the Loop

A record inside a single paper is a good start. It becomes a shared convention when authors use common fields and present supporting evidence in a form others can inspect. A reviewer can then challenge the record, a student can learn why the reported design survived, and another group can revisit a rejected candidate under the same conditions. Some variation in this scaffolding is healthy, but shared infrastructure gives groups a common base without requiring them to pursue the same research questions.

The computer architecture community has previously built shared responses to analogous coordination problems. SPEC provided common workloads, while simulators such as SimpleScalar and gem5 provided researchers with reusable experimental platforms. MLPerf and the long line of prediction and prefetching championships showed that we can agree on workloads, rules, and scoreboards. These shared objects did not settle every question, but they gave the field durable things to run, dispute, teach, and improve. Benchmarks do not capture the path through an adaptive search, but they show how common boundaries make comparisons meaningful. Agentic design now needs a similar layer for search state, allowed actions, failures, and independent checks.

When Amir Yazdanbakhsh and I first articulated the Architecture 2.0 vision in a SIGARCH blog post in 2023, it was conceived as a data-centric AI gymnasium, a shared ecosystem of data, benchmarks, and tools for ML-assisted architecture research. Three years later, many of those building blocks have emerged, including knowledge benchmarks such as QuArch, assembled with the help of more than 140 contributors across 40 institutions, capability evaluations such as ArchEval, and design-space infrastructure such as ArchGym. Building them has taught us something more important. The remaining challenge is not simply another benchmark, evaluation, or piece of infrastructure. A benchmark tests what a model knows, an evaluation tests what an agent can do, and infrastructure runs the search. Some of these systems log a run in detail, but that record stays inside the tool. What no published result yet carries with it is a portable account of how a study bounded its search, rejected candidates, and chose what to report, and that is the part we cannot supply by building one more tool.

Making It Routine

Making this kind of evidence part of everyday research practice will take deliberate community effort. Machine-learning communities have shown one path. Benchmarks and competitions provide participants with shared tasks and rules, while model cards and datasheets establish shared reporting expectations. NeurIPS requires submissions to include a paper checklist addressing reproducibility, transparency, limitations, and experimental details, a step it introduced to help authors document the completeness and limits of their work. ICML has likewise published paper guidelines, based on the NeurIPS checklist, that ask authors to document claims, limitations, code, data, and experimental details. A complementary perspective appears in the 2022 FAccT paper by Smith and colleagues on REAL ML, which argues that responsible machine learning depends not only on models and metrics, but also on documenting the broader research process.

Architecture conferences and workshops could experiment with a few concrete practices. Artifact-evaluation tracks can request versioned configurations, failures that affected the result, and at least one confirmation check that was not used to select the reported result. Competitions can specify workloads, allowed actions, limits on evaluator queries, stopping rules, and held-out tests to ensure scores remain comparable. We do not need to harden these practices into permanent rules at once, and venues can learn what helps reviewers and discard what does not. For proprietary work, the detailed record may remain internal, but a public claim still requires sufficient disclosure for outside groups to assess it. The simplest shared form for that disclosure is a single page. Authors could include or link to a one-page design-loop card summarizing the process in a consistent format.

Figure 3: One possible one-page record makes the bounds, actions, feedback, evidence, failures, and final decision visible.

These conventions also need a public home alongside tools, benchmarks, failure cases, and examples. The Architecture 2.0 hub is one possible starting point. Its value will depend on whether multiple groups use, challenge, revise, and help govern its contents.

No single convention will make AI for architecture an engineering discipline. The value of a shared record is that it lets a result move beyond the group that produced it so someone who was not there can check it, build on it, or challenge it when the evidence does not hold. The full rooms at ISCA were the momentum. Making the evidence travel with the design is what turns momentum into a discipline.

About the Author

Vijay Janapa Reddi is the Gordon McKay Professor of Electrical and Computer Engineering at Harvard University and a visiting professor at ETH Zurich. His work spans computer architecture, machine learning systems, and autonomous agents. He is Vice President and a board member of MLCommons and the author of the open-source Machine Learning Systems book.

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.

The conference

The 53rd International Symposium on Computer Architecture (ISCA) was held at the Raleigh Convention Center in Raleigh, North Carolina, from June 27 to July 1, 2026. Raleigh sits at one corner of the Research Triangle, anchored by North Carolina State University, the University of North Carolina at Chapel Hill, and Duke University. General Chairs Huiyang Zhou and James Tuck, both of NC State, led the organizing effort.

The most notable structural change this year was that ISCA offered remote attendance, making it a hybrid conference. The organizers provided deeply discounted remote registration to broaden access for students and researchers who could not travel, broadcast the main and keynote sessions on Zoom, and made recordings available to registrants for offline viewing. This was ISCA’s first hybrid offering and an experiment intended to lay groundwork for remote attendance at future architecture conferences.

Workshops and tutorials

Preceding the main symposium, ISCA 2026 opened with two full days of workshops and tutorials on Saturday, June 27 and Sunday, June 28, organized by Workshops and Tutorials Co-Chairs Lisa Wu Wills (Duke) and Brandon Reagen (NYU). The program totaled 15 workshops and 16 tutorials, spanning the full breadth of the field, from open-source infrastructure and DRAM to quantum computing, encrypted AI, and agentic design.

Saturday’s tutorials leaned on open-source and simulation infrastructure, such as ASTRA-sim, the Ramulator and DRAM Bender memory tools, and FAVA on formal hardware verification, while the workshops included gem5, SAFE AI on encrypted AI, and Architecture 2.0 on agentic AI for computing-systems design, which marked the launch of the book Architecture 2.0: Agentic Design Loops for Computing System Synthesis. Sunday leaned into mentoring, open-source hardware, and quantum: the uArch Mentoring Workshop and YArch’26 for students; XiangShan and the SODA Synthesizer on the open-source side; and FHE & Cheddar and Janus 4.0 for quantum, alongside the 6th DRAMSec, a carbon-accounting tutorial, and the Championship in Branch Prediction.

Panel on the Impact of AI on Higher Education & Computer Architecture @uArch 2026

The main program

This was the largest ISCA program ever. Program Co-Chair Carole-Jean Wu (FAIR, Meta) and Kevin Skadron (University of Virginia) reported 850 regular-track submissions, a 49% increase over the previous year, of which 161 were accepted, for an 18.9% acceptance rate (down from 23% the year before). To accommodate the volume, ISCA ran a fourth parallel track for the first time. 

The reviewing operation scaled to match. It involved 22 Area Chairs, 211 full PC members, and 192 lightweight PC members, by far the largest committee in the conference’s history. Reviewing ran in two rounds, with most papers reaching six reviews. Discussion followed the “Identify the Champion” model; 301 papers reached a clear online consensus, while the remaining 59 were resolved in a series of real-time Zoom PC meetings held over five days. In the end, 116 papers were accepted outright and another 45 were conditionally accepted with shepherding, all of which were eventually accepted.

Keynotes

ISCA 2026 featured three keynotes.

Debbie Marr (CEO and Co-Founder of AheadComputing) opened with “Computing at the Crossroads: Architecture, Economics, and the Next Era.” She reflected on the trajectories that shaped the field: Moore’s Law, Dennard scaling, increasing abstraction, and the long expansion of general-purpose computing. Many of those assumptions, she observed, are now being questioned simultaneously. She tied the technical inflection point to shifting economics, ecosystem dynamics, and leadership transitions, and suggested that the architecture community’s choices today will define the next era of computing.

The second keynote piloted a new “dialogue” format on quantum computing, pairing Fred Chong (University of Chicago; Chief Scientist for Quantum Software at Infleqtion) and Jay Gambetta (IBM Fellow and Director of Research) for “Architecting Hybrid Quantum-Classical Computing for Scale and Fault Tolerance.” Their shared theme: with fault-tolerant machines on the horizon and near-term machines increasingly integrated with classical HPC, computing will be heterogeneous and accelerator-based, and architects are needed to bridge theory and physical technology across applications, software, error correction, workflow management, and machine organization.

Babak Falsafi (EPFL) closed the keynote lineup with “Beyond the AI Energy Wall: Optimal Server Design and Operation”. He described how AI is pushing cloud infrastructure toward an energy wall, with compute demand growing faster than power, cooling, and datacenter capacity can be sustainably provisioned, and suggested that clearing it requires full-stack optimization rather than simply scaling accelerators or building larger facilities. He questioned the long-standing assumption that single-thread performance should dominate server design and operation.

Keynote by Debbie Marr (Computing at the Crossroads)

Awards

A number of the community’s honors were presented during the conference.

The ACM/IEEE-CS Eckert-Mauchly Award went to Srinivas Devadas (MIT) for pioneering contributions to secure architectures with broad industrial and academic impact. The ACM SIGARCH Maurice Wilkes Award was presented to Tushar Krishna (Georgia Tech) for outstanding contributions to architectures and modeling tools for large-scale AI systems. The TCCA Young Architect Award went to Akshitha Sriraman (Carnegie Mellon University) for contributions to the design and management of efficient and sustainable cloud datacenters. The ACM SIGARCH/IEEE CS TCCA Outstanding Dissertation Award went to Olivia Hsu (Stanford University), with an honorable mention to Jovan Stojkovic (University of Illinois Urbana-Champaign). The SIGARCH Alan D. Berenbaum Distinguished Service Award was presented to Sarita Adve (University of Illinois Urbana-Champaign) for sustained and transformative contributions to ACM SIGARCH, the broader architecture community, and via CARES, the ACM SIG ecosystem. The ISCA Influential Paper Award recognized “Adaptive Insertion Policies for High Performance Caching” (ISCA 2007) by Moinuddin K. Qureshi, Aamer Jaleel, Yale N. Patt, Simon C. Steely, and Joel Emer, for its commercial impact and for reinvigorating research on cache management with an elegant set-dueling framework that can be broadly applied to cache-policy selection.

Two ISCA Best Paper Awards were selected from a field of five nominations: “Cerberus: Cross-Layer ECC Co-Design for Robust and Efficient Memory Protection” — Junhwan Kim, Seunghyun Kim, Yesin Ryu, Saeid Gorgin, and Jungrae Kim. “Patterns Behind Chaos: Forecasting Data Movement for Efficient Large-Scale MoE LLM Inference” — Zhongkai Yu, Yue Guan, Zihao Yu, Chenyang Zhou, Zhengding Hu, Shuyi Pei, Yangwook Kang, Yufei Ding, and Po-An Tsai.

Two ISCA Distinguished Artifact Awards were also recognized: “Transpiler-Architecture Co-Design to Curb Clifford Costs in Fault-Tolerant Quantum Computing” — Meng Wang, Chenxu Liu, Samuel Stein, Yufei Ding, Poulami Das, Prashant Nair, and Ang Li. “Towards Practical Interrupt Side-Channel Attacks on macOS for Apple Silicon” — Xin Zhang, Chang Liu, Jiajun Zou, Yi Yang, Qingni Shen, Zhi Zhang, and Trevor E. Carlson.

ISCA Influential Paper Award recipients

Industry track and artifact evaluation

The Industry Track, chaired by Brad Beckmann (AMD), accepted 11 papers out of 27, reviewed by a 32-member committee drawn entirely from industry across a diverse set of startups and established companies. The accepted set ranged from silicon to software. Two additional papers were recommended for an IEEE Micro Special Issue on Commercial Products.

Artifact Evaluation, in its fourth year at ISCA, received 49 submissions. 42 papers earned all three badges (Available, Functional, and Reproduced), 3 earned Available and Functional, and 4 earned Available. The co-chairs Hyeran Jeon (UC Merced), Linghao Song (Yale), and Mark Zhao (University of Colorado Boulder) flagged a growing challenge: the increasing heterogeneity of hardware and software platforms, which reviewers do not always have access to.

A snapshot of the Industry Track session

Excursion

ISCA’s excursion was an evening dinner and social at Raleigh’s historic City Market. Built in 1914 and known for its cobblestone streets and early-twentieth-century lamplight, the district hosted a relaxed, open-air affair, with food stations of North Carolina–inspired dishes, beer, and wine spread across the historic Market Hall, The Grove, and the outdoor spaces between them. With attendees spilling across the market, it made for an excellent networking opportunity and a welcome chance to unwind and catch up with people after the intensity of the technical program.

Excursion venue: City Market

About the author: Bingyao Li is an Assistant Professor in the Computer Science and Engineering Department at the University of California, Riverside. Her research focuses on designing architecture and system features for next-generation GPU platforms and building high-performance LLM infrastructure and systems.

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.

The Return of Rigorous Full-System Timing Simulation

Accurate timing simulation remains one of the most important tools in computer architecture, but modern systems have made cycle-level simulation increasingly impractical. Today’s platforms combine many-core CPUs, deep memory hierarchies, accelerators, complex I/O, and large software stacks, making detailed simulation extremely slow—often requiring months to simulate seconds of execution. This “timing simulation wall” has pushed researchers toward approximations such as application-only simulation, fixed instruction windows, or instruction windows representing only the workload. While these reduce runtime, they often sacrifice rigorous end-to-end measurement of real microarchitectural behavior.

This blog argues for a return to rigorous full-system timing simulation—not by simulating everything in detail at all times, but by measuring the right execution intervals, using the right performance metrics, and applying statistically sound methods to make accurate simulation practical again.

Why Full-System Simulation?

Full-system simulation emulates an entire computer system: CPU, memory, devices, operating system, and applications. Unlike user-level simulation, it captures interactions across the full software and hardware stack. Full-system simulation matters because many critical behaviors emerge from OS activity, interrupts, I/O, memory management, synchronization, and device interactions—not from application code alone. Ignoring these layers can misrepresent real system bottlenecks and performance.

Full-system simulation dates back to the 1990s with systems like SimOS, later influencing platforms such as Simics (now Intel Simics Simulator), M5 (integrated into gem5) and QEMU (used in MARSS and QFlex).

Today, full-system simulation is becoming essential again for four reasons:

1. Modern workloads are service-oriented and multi-tenant, relying on microservices, RPCs, storage stacks, and OS-mediated interactions.
2. Many server and mobile workloads spend significant time in the OS, making kernel behavior central to performance analysis.
3. Heterogeneous systems increasingly combine CPUs with GPUs, accelerators, and smart NICs, with the CPU and OS orchestrating coordination, memory, and synchronization.
4. Agentic AI workloads depend heavily on tool invocation, scheduling, APIs, databases, and system integration, making CPU and OS behavior critical to end-to-end performance.

As a result, full-system simulation is no longer just a legacy methodology—it is increasingly necessary because the entire system stack has become the target of architectural innovation.

The Timing Simulation Wall

Simulators span a broad spectrum of abstraction, functionality, and performance. At the fastest end are execution-driven full-system simulators that use JIT translation to dynamically map target ISA instructions into the host ISA at runtime. Since early systems such as SimOS, these simulators have typically operated within roughly an order of magnitude of native hardware speed.

Modern ISA emulators such as QEMU can additionally generate detailed execution traces for functional simulation, enabling analysis of cache and TLB miss rates, branch predictor behavior, and prefetcher accuracy. This tracing introduces another order-of-magnitude slowdown relative to native execution.

Timing simulators go further by modeling cycle-level interactions among microarchitectural components in the CPU, accelerator, memory and I/O devices resulting in substantially lower simulation throughput. The table below compares simulation speeds for a single ARM Neoverse N1 target core with its cache hierarchy running server workloads on an AMD Zen 3 host.  The first row presents QEMU’s raw ISA emulation speed. The second row shows the slowdown due to instrumentation for user-level functional simulation. The third row demonstrates the impact on speed when functionally simulating the microarchitectural components, including the cache hierarchy and TLBs, front-end tables, and data prefetcher, for all user-level instructions. The fourth row shows the impact of functional simulation of all instructions, including the OS. Finally, the fifth row shows the timing simulation speed.

Modern workloads are not steady streams of similar instructions. Their performance fluctuates over time due to network activity, resource contention, background OS activity, synchronization effects, software hiccups, DVFS throttling, UI and graphics activity, and other asynchronous events. Alameldeen et al. presented a statistically rigorous methodology to determine the minimum measurement window needed to capture workload performance variability within a specified error bound and confidence level. 

Unlike conventional database workloads (e.g., TPC benchmarks) which have prescribed measurement windows, typical benchmarks and workloads used in research do not. Applying Alameldeen’s methodology, we find that capturing performance variability for a single ARM Neoverse N1 core and its cache hierarchy requires five to 120 seconds of target execution time across server workloads from CloudSuite, DCPerf, and DeathStarBench. Simulating even a few seconds of a single core with today’s fastest cycle-accurate simulator, gem5, at 250 KIPS requires months of simulation time.

What Should We Measure?

The second question is which performance metric to use. Timing simulators count cycles, so architects often report IPC, or instructions per cycle. IPC is reasonable for single-core workloads when most executed instructions correspond to program progress.

For multicore workloads, however, IPC can be misleading. Threads may spin, poll, block, wait on locks, synchronize, or execute OS code that does not advance useful work. A system can therefore sustain high IPC while making little forward progress; in effect, total IPC can reward busy waiting. 

This is why user-level IPC, or U-IPC, is often a better proxy. U-IPC counts user-level instructions over time, assuming that user instructions per request remain roughly stable and that most spinning occurs in the OS. Under that assumption, U-IPC tracks useful throughput more directly than total IPC.

But U-IPC must be validated for each workload. If spinning occurs in user space, as in systems with user-level network stacks, raw U-IPC still counts non-productive work and must be corrected to exclude spinning. The broader requirement is therefore metric validation: a rigorous simulation methodology must show that the chosen metric—IPC, U-IPC, throughput, or latency—actually captures forward progress for the workload under study.

How Should We Measure?

Due to the timing simulation wall, researchers often use abbreviated measurements. The most common technique is to measure a single unit of 100 million to one billion instructions. Unfortunately, depending on where in the execution the fixed measurement is taken from, this technique may lead to inconclusive results or worse, incorrect conclusions. 

Instead, designers often use sampling to capture variability in performance estimates. Phase-based sampling, such as SimPoint, is a popular technique that uses clustering of basic-block vectors (BBVs) to select representative application “phases.” Such sampling properly captures the representing repetitive instruction streams that account for most of the execution. 

While simple and practical, phase-based sampling may ignore OS effects, interrupts and I/O interactions, communication among cores, and software hiccups. Moreover, Wunderlich argues in his thesis that phase-based sampling: (1) misses the microarchitectural footprint of less common instruction streams and their impact on performance, and (2) forgoes any error bounds with confidence in estimates.

A rigorous sampling technique is statistical sampling, such as SMARTS, taking a large sample (e.g., hundreds) of small (e.g., 200k cycles), uniformly distanced measurement units that is representative of execution, not phases in the workload. This technique enables bounding the error in estimates and delivers quantifiable confidence. It also opens an entire plethora of statistical sampling tools to trade off confidence in estimates for measurement in speed and quantify sample divergence to detect bias in estimates.

The figure below compares error magnitude in performance estimates among three abbreviated measurement techniques from full-timing simulation runs of tens of target seconds on a two-core socket with 2.0 GHz ARM Neoverse N1 cores running single-tier, multi-tier and consolidated server workloads (CloudSuite, DCPerf and DeathStarBench). The figure compares the error against the full-timing baselines for: (1) single units of one billion instructions per core starting from three equally distanced positions in the minimum measurement window (i.e., beginning, 1/3 and 2/3 into the population), (2) units of 100 target microseconds (i.e., 200k cycles for a 2.0 GHz clock) including basic-block vectors (BBV) derived from K-means clustering, and (3) a uniform sample (of hundreds) of 100 target microseconds drawn with an error bound of 5% with 95% confidence with statistical sampling. 

Both one-billion instruction units and BBV result in high error estimates with the former not being representative of execution and the latter representing only frequently executed instructions. In contrast, statistical sampling results in a desired error bound with confidence because it represents not just frequently executed instructions but also instructions that have a high impact on performance due to their microarchitectural footprint.

A SOTA Sampling Framework

The figure below presents a state-of-the-art sampling framework using QFlex 3.0 (derived from SimFlex) for full-system timing simulation of ARM ISA. For each workload, the software stack together with the OS is first loaded and warmed on a real platform, then tested to identify the minimum window—such as five to 120 target machine’s seconds—called a “population”, using Alameldeen et al.’s technique. The workload is then loaded again, this time with QEMU and run through a functional simulator running on average at 6 MIPS for the entire duration of population. 

The functional simulator simulates all microarchitectural components with long-term state (e.g., cache hierarchy and TLBs, branch tables, data prefetcher) and periodically dumps checkpoints with architectural and microarchitectural state into a checkpoint library. Because the functional simulator is not cycle-accurate, it requires an approximation for time. The most common approximation is IPC=1 or IPC derived from neighboring units.

The checkpoints in the library are then run using a timing simulator for 100 us independently and embarrassingly parallel. Each checkpoint is first run for a bounded window of time (e.g., 200 us) to make sure microarchitectural components with short-term state (e.g., buffers in the pipeline, cache hierarchy and NoC) are warm, followed by a measurement. The timing results for the sample are then aggregated to determine whether the sample (i.e., number of checkpoints) is large enough to bound the error for a desired level of confidence (e.g., 5% with 95% confidence). If not, the sampling framework creates a new checkpoint library with a shorter interval between checkpoints.

Challenges and Open Problems 

Even with accurate measurement techniques, there are fundamental challenges with sampling (for both phase-based and statistical sampling).

1. Accurate state generation. Timing-induced activity during functional simulation and its impact on the microarchitectural footprint may result in a significant bias because time is approximated. This challenge is more pronounced with variable performance among target threads in multi-tier and consolidated workloads where the speed bias may significantly impact the resulting shared microarchitectural footprint.
2. The functional simulation wall. Sampling minimizes the required measurement using timing simulators but shifts the bottleneck to the functional simulator (which at 6 MIPS is only 24x faster than a 250 KIPs timing simulator). Parallelizing functional simulation may be a promising approach to enable scalability with multicore hosts. Parallel simulation is fundamentally limited by the granularity at which target threads communicate.
3. Support for checkpointing. Generating and restoring an entire checkpoint for every measurement is impractical in both storage capacity and runtime overhead. Practical sampling therefore requires incremental checkpoint storage and restoration.
4. Sampling non-average metrics. Statistical sampling works well for average-like metrics such as IPC or U-IPC, but it is harder to apply to extreme or rare-event metrics such as maximum temperature, worst-case power, or rare latency spikes.
5. Capturing service-level metrics. Metrics such as request latency or p99.9 latency are much coarser-grained than sampling units needed for IPC or U-IPC. Capturing service-level metrics and tail latency may require an order of magnitude larger population and sampling units which poses a challenge for both functional and timing simulation.
6. Multi-node full-system simulation. Many modern workloads are distributed across multiple machines. Single-node simulation is often insufficient for datacenter-scale behavior, but despite progress, rigorous  multi-node full-system timing simulation remains an open challenge.
7. Interoperability across simulators. A practical ecosystem should allow one tool to generate a checkpoint library and another to perform timing simulation. This interoperability requires an interface definition language allowing interoperable architectural and microarchitectural state among simulators.

About the Authors

Shanqing Lin is a final-year PhD student at the School of Computer and Communication Sciences at EPFL and the principal developer of QFlex v3.0.

Mohammad Alian is an Assistant Professor in the Electrical and Computer Engineering Department at Cornell University.

Babak Falsafi is a Professor in the School of Computer and Communication Sciences at EPFL (epfl.ch) and the founding President of Swiss Datacenter Efficiency Association (sdea.ch).

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.

What does speculative execution in a processor — and the predictor that drives it, such as a branch predictor — have to do with AI agents? They may seem very different, yet, at a high level of abstraction there are similarities.

Both speculate: A processor predicts which way a branch will go and begins executing instructions along the predicted path before the branch has resolved. An AI agent infers a user’s intent, reads/writes files, executes programs, makes network calls etc., before it knows whether its interpretation of the user’s intent is right.

Because prediction can fail, both systems require roll back mechanisms. In a processor, once a misprediction is detected, the wrong path work disappears (from the programmer’s point of view). When the agent is told it is wrong, or figures that out itself, it may revise its plan and redo the work after rolling back to a good checkpoint.

Both systems litter and leave residues: While a processor can recover from a misprediction without any programmer visible effects, under the covers, microarchitecturally, wrong path execution perturbs on chip structures like caches. The Spectre attack (2018) showed that this residue can be observed through covert channels. AI agents have a similar problem. When an agent, or its human user, notices a mistake and corrects it, the failed attempt can leave at least two types of residues: a) residue that is easily observable like bad outputs, stale files or processes, or b) harder to know/track/undo residue like timing and volume of network requests, model context summaries shipped to third party servers to name a few.

Also both systems can be tricked and steered through adversarial inputs: In Spectre, the attacker influences the on chip predictor state by executing a pattern, then supplies an adversarial input that causes the victim to transiently execute along the trained path that it should not take architecturally. While that transient execution is later squashed the microarchitectural residue of the execution can still be measured. Malicious prompts can play a similar role in AI agents: they can steer the system toward actions that are later corrected or denied, but in the process may leave litter data that attackers can use.

Given these similarities, we can ask two questions.

1) Can AI agents completely eliminate easily observable “architectural” residues on mispredictions?

2) What are the dangers/risks of hidden “microarchitectural” residue left behind by AI agents?

Regarding architectural residue, processors can hide speculative wrong path work cleanly because the ISA defines what counts as visible committed state. Currently there is no equivalent for AI agents: the absence of an interface that can precisely define operations, state, life time of state, and triggers for misprediction recovery, makes these systems hard to reason about and a fertile ground for leakage.

While observable residue is a serious problem it is also a solvable problem to some degree: if one is satisfied with imprecise, best effort work, one simple thing to do is to just prompt the agent to clean up after itself. A really smart agent, in theory, should be able to use mechanisms like transactions, two phase commit, distributed undo protocols, disposable containers and VMs, sandboxes, access controls, versioning and information flow tracking to minimize overt residues. However, if we wanted to do better than prompting we probably will need an ISA-like layer.

The second, and harder, question is about what happens to hidden/microarchitectural residues. In general, clean up of this type of residue is hard because it is often left in places no one thinks to inspect, or in places users cannot practically inspect because the those parts are proprietary or distributed across organizational boundaries. Also with AI agents, the problem is broader in scope than in a processor because it spans a larger number of tech layers from model context to hardware, local and remote. Further, an agent’s speculation window may last seconds or minutes, compared with nanoseconds in a processor. That longer window creates more opportunity for residue to diffuse. It is highly unlikely that we can simply prompt the agent to clean up hidden/microarchitectural residue because, by definition, there isn’t an architectural interface to observe or control microarchitectural state/work.

How likely are we to solve agentic littering? Who needs this problem solved? And, who should solve this problem?

In addition to technical aspects, economics and incentives often determine whether solutions are adopted. Here too we can look at processor misprediction recovery and compare them to AI agents.

Overt architectural and hidden microarchitectural residues have different economics and incentives at play.

Overt residues are easier to price. If an agent leaves behind a directory full of junk, consumes too many resources, or corrupts a file, that failure is visible to users. Users will complain, and because there are complaints, product teams can justify spending resources to fix them.

Hidden residues are harder. These residues may not produce an obvious effect like a crash. They may also require complex conditions to manifest. That makes it harder to attribute with accuracy and consequently easier to dismiss. It also makes it harder for users to demand fixes, because users often cannot see the thing they are supposed to complain about.

Spectre, an issue due to adversarial steering and microarchitectural residue, was disclosed roughly eight years ago, and the broader class of this leakage has still not been completely fixed. This is not because principled technical solutions do not exist. It is because these solutions increase design complexity, impact performance, change the hardware and software interface in ways that is not easy to adopt, or require coordination across vendors and different layers of the computing stack all of which add recurring or non-recurring costs. Also, each layer can plausibly say that the residue cleanup should be handled by someone else. Vendors can also say that there are have not seen large scale attacks and that they do not have to protect against these attacks given the risk profile.

The same pattern may emerge for AI agents and handling hidden/microarchitectural residues.

Each AI agent boundary is also an economic boundary. Each layer can plausibly say that the residue is someone else’s problem. The model provider can say the deployment should isolate side effects. The deployment/orchestrator can say the runtime should enforce cleanup. The runtime can say the operating system should provide better isolation. The hardware vendor can say software should avoid sensitive colocation. The user experiences the combined risk of all these but usually has the least ability to inspect or repair it!

The real answer is that every party involved in agentic execution should fix its own leaks and share responsibility for security and privacy. But each party also has reason to argue that the cost is too high, especially when the economic benefits are difficult to measure and the harms are difficult to attribute.

So the likely outcome here is not hard to guess. Hidden microarchitectural residue handling is treated as an afterthought, and agents end up reflecting the incentives that shaped it, viz., agents get more capable, overt residue cleanup improves through ad hoc clean up attempts, and create a very long tail of hard to detect, microarchitectural residues that expands the attack surface.

The best chance for security is while these systems are being designed and deployed. AI-agent platforms designed now should at least treat residue management as first-class design requirement. That, however, means finding ways to incentivize designers to care about hidden, microarchitectural residue before users are harmed. If we treat microrchitectural residue management as an optional, “nice-to-have”, “less-important-than-overt” security feature, we will spend the next decade patching a massive, distributed attack surface.

About the Author: Simha Sethumadhavan is a Professor in the CS department at Columbia University. He would like to thank  Profs. Roxana Geambasu. Martha Kim and Tanvir Ahmed Khan for thought provoking comments and feedback.

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.

Architecture & Systems are Changing: The Architect’s Role in the Era of Agentic Co-Design

The AI datacenter stack is built on hardware-software contracts and abstractions that were never designed for the workloads datacenters now serve. Memory systems strain under terabyte-scale capacity. Heterogeneous accelerators have been pressed into deployment. With datacenters projected to consume over 1,000 TWh annually, surpassing Japan (the world’s fourth-largest economy), renegotiating the hardware-software contract is no longer optional.

AI was enabled by decades of hardware and software efficiency gains. The next leap requires two orders of magnitude more, on a stack whose workloads, infrastructure, and economics bear little resemblance to the one the contract was written for.

That is not a problem any single layer of the stack can solve. It is a co-design problem, and it is unfolding while the design process itself is changing across systems and architecture.

The contract so far

Computer architecture has long been guided by a quiet contract with three commitments: abstractions, interfaces, and transparency. Layers that hide hardware complexity from programmers; interfaces like the x86 ISA that let decades-old binaries still run on Linux today; and microarchitectural state largely hidden behind a model programmers can keep in their heads. Together, these commitments deliver the property programmers care about most: programmability.

This contract is not arbitrary: it is what lets billions of lines of legacy software keep running while architects rebuild underneath. But the contract was negotiated for a world where humans wrote all of the code and humans designed all of the hardware. Both halves of that world are changing at the same time, and the architect’s job is evolving with them.

Plenty of room at the Top

In 2020, Leiserson, Thompson, Emer, Kuszmaul, Lampson, Sanchez, and Schardl argued in Science that post-Moore performance gains would have to come from the “Top” of the computing stack: software, algorithms, and hardware architecture, rather than from the “Bottom” of semiconductor physics. They were right, and the half-decade since has only sharpened the point.

The harder claim in that paper is the one we want to dwell on. The Top has plenty of room, but the gains are “opportunistic, uneven, and sporadic,” subject to diminishing returns. The Top has historically been mined by hand, one paper and one design cycle at a time. What is changing now is the rate at which it is mineable. The two directions we describe next change that rate. Same Top, mined faster, mined more systematically, and mined by tools the field did not have until recently.

Two directions are reshaping the design loop

Two complementary directions are converging on how we build system software and hardware: embedding learning inside low-level mechanisms, and using AI agents to explore the architectural design space itself.

The first direction has a deep history. Perceptron-based branch predictors put a lightweight learning model on the critical path more than two decades ago, and the catalog has steadily grown since. On the cache-hierarchy side, Mockingjay uses a trained reuse-distance predictor to imitate Belady’s optimal replacement policy. On the prefetching side, Hashemi et al. framed memory access patterns as an LSTM prediction task, Pythia recast the entire prefetcher as an online reinforcement-learning agent, and Micro-Armed Bandit showed that lightweight bandit-based RL can match more complex agents at a fraction of the storage cost. Outside the cache hierarchy, reinforcement learning has been applied to chip floorplanning, learning-based memory allocation replaced hand-tuned allocator heuristics with predictors trained on real telemetry, and Seer applied deep learning to predict QoS violations in cloud microservices before they materialize. Most recently, our work on learned virtual memory (LVM) eliminated address-translation overhead with a learned index that fits in two cycles of integer arithmetic. The principle generalizes: fixed designs are being replaced with principled, hardware-realizable models that adapt to workload shifts in ways hand-tuned heuristics cannot.

The second direction is newer, and arguably more disruptive. AlphaEvolve demonstrated that LLMs paired with evolutionary search can discover algorithms across domains, from mathematical constructions to data-center scheduling. ADRS extended the idea to broader systems research, and recent work from Google has applied the same approach to cache replacement. The same paradigm has reached the software side of the machine: agentic systems that generate and tune CUDA and Triton kernels, including NVIDIA’s AVO and Meta’s KernelEvolve, are now in use across heterogeneous accelerators. Sankaralingam captured the bigger picture in Computer Architecture’s AlphaZero Moment, arguing that the field is approaching a regime where architectural discovery itself becomes a search problem, beyond per-mechanism tuning. In our own recent work, Agentic Architect, we coupled LLM-driven code evolution with cycle-accurate simulation to explore microarchitectural design spaces, and found that the loop matches or exceeds state-of-the-art designs on cache replacement, prefetching, and branch prediction. 

These two directions are not alternatives. They differ in what they decide and when. The first decides how a fixed mechanism behaves at runtime: a branch predictor that learns its own weights, a cache policy that adapts to the workload. The second decides what the mechanism looks like in the first place: the predictor, the policy, the prefetcher itself, evolved before deployment. Both move judgment that used to live in tight loops written by experts into search problems that can be scored and re-evaluated.

Figure 1. Agentic Architect, a framework for Computer Architecture Design Space Exploration and Optimization.

Why the loop closes here

Computer architecture has a structural advantage that is easy to take for granted: from the beginning, the field has organized itself around shared, quantitative empirical evaluation. SPEC, PARSEC, CloudSuite, DeathStarBench, and a long list of others encode a community-wide agreement about what a “fair comparison” looks like. The metrics are equally well established: IPC, MPKI, miss rates, area, power, energy-delay product. Every paper in the field is, in effect, a measurement against an agreed instrument.

An agentic loop needs exactly this kind of discipline to close. The loop’s productivity is bounded by the cost and clarity of its fitness signal: how cheaply can a candidate be evaluated, and how reliably does the resulting score reflect the property we actually care about? In domains where evaluation is subjective, expensive, or contested, agentic exploration struggles. In computer architecture, the cycle-accurate simulator gives the loop reproducibility: controlled-environment evaluation against well-defined metrics. Production profiling, hardware performance counters, tracing, and system telemetry give it realism: behavior under load and access patterns that synthetic benchmarks cannot reproduce. The two together are what close the loop.

That has a practical consequence. It means the field does not have to invent its evaluation infrastructure to take advantage of agentic co-design; it has to connect it. The benchmarks, the simulators, and the metric vocabulary are already in place. What is missing is the throughput and the integration: simulators that can serve hundreds of evaluations per study, fitness functions that compose IPC with area and power as primary terms, and training/evaluation splits that let us measure generalization instead of overfitting. We will return to this agenda below.

When code is co-authored, what does “programmable” mean?

Some of the architectural conservatism we aimed to maintain was justified, decades ago, by a single phrase: but no one will program it. The Cell processor’s programmer-managed SPEs and local stores are an example: an elegant design that proved very hard to program in practice.

The cost of programmability used to be borne almost entirely by humans. That is no longer true, and it changes the calculation.

In April 2025, Satya Nadella reported that 20% to 30% of Microsoft’s code was AI-generated, with internal acceptance rates rising monotonically. Google sits in a similar regime: a quarter in Q3 2024, half by fall 2025, and 75% of Google’s code by April 2026, with Sundar Pichai describing the shift as “truly agentic workflows” in which engineers orchestrate fleets of AI agents rather than writing each line themselves.

These numbers describe authorship of characters, not accountability. But they should change how we evaluate the programmability constraint. When agents can routinely program across ISAs, generate platform-specific code paths, write test harnesses, and bridge unfamiliar interfaces given a clear specification, the cost on the programmer is no longer a sufficient veto on a hardware design choice. Designs that were dismissed because they imposed too high a cost on human programmers warrant a fresh look when most of that cost falls on agents instead.

Programmability still matters. Clarity, debuggability, verifiability, and predictable performance remain real properties humans need, and increasingly properties agents need too. Abstractions still matter, perhaps more than ever. Deciding which to expose, which to hide, and which to make machine-checkable is now a question for the programming-languages and systems community alongside architects. But the most consequential lever may not be what we add; it may be what we remove. Many of the layers in today’s stack exist to hide hardware from human programmers and cost cycles and area to maintain. When agents absorb that complexity, the layers come off, and the performance and efficiency we have been paying to abstract away come back.

A widening design space

Reshaping the loop only matters if the space it has to cover is tractable. Increasingly, it isn’t.

A modern AI datacenter spans CPUs, GPUs, AI accelerators, a widening memory landscape (DRAM, CXL, HBM, HBF, SSD), and rack-scale integration with NVLink and optical interconnects. The software and hardware layers have not caught up: a single agentic query may dispatch dozens of model invocations across heterogeneous devices and tool calls on CPUs, all with different abstractions. The operating system (OS), the layer that has historically reconciled such mismatches, must evolve at an unprecedented pace to keep up with growing hardware capabilities and software demands. For example, it only has partial visibility into the GPU, despite its prominent role in AI workloads. Our recent work LithOS has established a beachhead for OS-level control over GPUs, but extending that contract to coordinate the full heterogeneous stack is open. At every level of that stack, energy and power are hardening from secondary considerations into primary constraints.

Each of these pressures is, individually, a multi-year research program. Together, they describe a design space defined by heterogeneous compute, evolving memory hierarchies, rack-scale integration, software-level coordination, and workload regimes that did not exist five years ago. Covering this space by hand is increasingly difficult, even for a large team of architects.

That is the practical case for agentic co-design. The space is outgrowing human-only exploration, and the tools to cover it are finally here.

A proof point

In our recent work, we introduce the Agentic Architect, an agentic framework for architecture design space exploration and optimization. We evaluate it across three of the most studied microarchitectural domains: cache replacement, data prefetching, and branch prediction. We chose them precisely because they are mature. They have decades of literature, well-understood baselines, and limited remaining headroom; if the loop produces gains in these domains, the result is meaningful. The evolved cache replacement policy matched and slightly exceeded Mockingjay; the evolved prefetcher beat SOTA by 17%; the evolved branch predictor improved over Hashed Perceptron on workloads where branch behavior is the bottleneck.

Figure 2. Storage versus performance for data prefetchers. The evolved prefetcher (87 KB) is Pareto-optimal: it delivers the highest geomean speedup over no prefetching at a smaller storage budget than the next-best design.

The more interesting result is what the loop discovered, and what it didn’t. The components in the evolved designs are almost entirely known techniques: stride engines and delta correlators for prefetching, reuse-distance predictors and signature tables for replacement, perceptron variants for branch prediction. None of these primitives is new.

What is new is the coordination. The evolved prefetcher continuously re-evaluates each predictive engine and throttles speculative ones under memory pressure. The evolved replacement policy arbitrates between three independent predictors based on their recent accuracy. The recurring structure across all three domains is the same: preserve the seed’s core, add orthogonal known features, integrate them through new coordination, and adapt at runtime. The novelty lies in the coordination. The loop refines the foundation; the architect still chooses it.

The infrastructure needs to evolve

If agentic co-design is going to do useful work across this design space, the bottleneck moves to infrastructure. The benchmarks and metrics are already there. What we need to build is throughput, multi-objective scoring, and cross-layer reach. The agenda is concrete:

• New tools for agentic architecture design space exploration. Cycle-accurate simulators were built for human-paced experimentation; an agentic loop wants hundreds of evaluations per study, with storage, area, power, and timing as terms in the score rather than afterthoughts that disqualify the result later. We need simulators, search strategies, and metrics purpose-built for this regime: search loops that respect hardware constraints and balance exploration against exploitation, and composite metrics that combine performance, area cost, and generalization into signals the search can rank against.
• Cross-component and cross-layer co-evolution. Co-design across the OS/hardware boundary is now the norm rather than the exception. Taking virtual memory as an example, TLB design, page-table walkers, translation footprint in the caches, and huge-page promotion in the kernel are tightly coupled, and optimizing any one in isolation may capture only a fraction of the available improvement. RTL backends, full-system simulators, and formal verification each let the loop close around a different surface.
• Open source has to evolve. Releasing code is no longer enough. We need structured artifacts that span the full stack, from prompt, seed, and scoring function down to traces, simulator and system configurations, and where applicable RTL, packaged so an agent can clone a repo, re-run the search that produced a published result, and compare new candidates against the same baseline.

The architecture and systems communities are uniquely positioned to drive that work.

Renegotiating computer architecture and systems

A stack co-authored by humans and agents needs renegotiation along the three axes of the old contract. Each is now reweighed against a new deliverable: programmability for agents and humans alike, rather than humans alone.

Abstractions. Many layers exist precisely to hide hardware from human programmers, and they cost cycles and area to maintain. With agents absorbing that complexity, some of those layers can come off; performance and efficiency we have been paying to abstract away come back.

Interfaces. The boundary between hardware and software was drawn for human programmers. As agents become the primary author of low-level code, the interface that carries the contract forward needs redrawing: machine-checkable, composable, and accessible to tools rather than only to humans.

Transparency. The property that lets a programmer model the CPU in their head gives way to a stricter need: explainability. The architect must verify the result against intent, explain why it works, and check that it generalizes beyond the workloads it was trained on. None of these come for free; the field needs methods, metrics, and tooling that make them routine.

Leiserson and colleagues told us in 2020 that there was plenty of room at the Top of the computing stack. The half-decade since has been about confirming they were right; the next half-decade will be about whether we build the tools to actually live there. Agentic co-design, paired with learning embedded inside the system itself, is a strong candidate for addressing the “opportunistic, uneven, sporadic” character that delivered those gains so far.

Architecture is changing. The contract still holds, but the terms are up for negotiation. The next generation of the stack will be defined as much by what we remove as by what we add. The people best positioned to make those calls are the ones who understand both the hardware and the software. That is, by definition, our community.

Acknowledgments

Thanks to the Computer Architecture & Operating System (CAOS) group at Carnegie Mellon and to Prof. Alex Daglis and Prof. Todd Mowry for feedback on this post.

About the Author

Dimitrios Skarlatos is an assistant professor in the Computer Science Department at Carnegie Mellon University. His research bridges computer architecture and operating systems with a focus on AI datacenter efficiency, privacy, and scalability. His work has been deployed in production datacenters and upstreamed into the Linux kernel. He has received the IEEE CS TCCA Young Computer Architect Award, the NSF CAREER Award, the Intel Rising Star Award, a Linux Foundation Faculty Award, an ISCA Best Paper Award, two ASPLOS Best Paper Awards, a CACM Research Highlight, four IEEE MICRO Top Picks, the joint ACM SIGARCH & IEEE CS TCCA Outstanding Dissertation Award, the David J. Kuck Outstanding PhD Thesis Award, and over a dozen industry faculty awards from Amazon, AMD, Intel, Meta, Oracle, and VMware. His recent work led to the founding of LithosAI.

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.

TL;DR: The history of parallel computing is a history of shifting what we put at the center of the computer. The first axis, control-level parallelism (CLP), is control-centric and schedules around the program counter: it gave us the high-performance computing (HPC) era. The second axis, data-level parallelism (DLP), is data-centric and schedules around tensors: it gave us the artificial intelligence (AI) era. A third axis is now emerging: value-level parallelism (VLP), where narrow data bitwidth exposes a small number of unique values and lets the architecture deduplicate redundant computation. Two recent works, Carat (ASPLOS ’24) and Mugi (ASPLOS ’26), make the case concretely: VLP eliminates redundant computation in both linear and nonlinear operations on AI workloads. This article argues that VLP is not a point of optimization but the beginning of a value-centric computing paradigm, one that is crucial for addressing the escalating energy demands of next-generation intelligent systems.

Traditional Parallel Computing

The First Axis: Control-Level Parallelism

The HPC era saw a diverse set of workloads. The metric of success made the goal explicit: instructions per cycle (IPC) normalizes performance to how fast instructions are consumed, not to what data the instructions are operating on. Therefore, computer architecture in the HPC era was control-centric. Michael Flynn formalized the design space in 1966 with his taxonomy [1]: SISD, SIMD, MISD, MIMD, outlining the orthogonality of instruction and data. For decades, this was the right framing: transistors were scarce, control logic was expensive, and the most valuable thing an architect could do was to issue one more instruction per cycle. 

The actual implementation to exploit the CLP to execute multiple instructions in parallel arose from the independence between instructions. We enjoyed the technology evolution from pipelining, branch prediction for SISD, superscalar issue, out-of-order execution, simultaneous multithreading, chip multiprocessors for MIMD and beyond.

The Second Axis: Data-Level Parallelism

Entering the AI era, powered by large language models (LLMs), transistors became plentiful but the memory bandwidth became scarce due to the large data volume in AI tensors. Consequently, we hit the memory wall and turned to data-centric architectures, expanding more along the data dimension in Flynn’s taxonomy. Success is now measured by how well we apply one operation to many data elements while feeding them efficiently from memory (e.g., throughput, goodput, and arithmetic intensity). TPUs with systolic arrays and GPUs with tensor cores are renowned examples to exploit the rich DLP opportunities from high-dimensional tensors.

Diving deeper, we see that compute arrays, i.e., dataflow architecture, are becoming the first class citizens. Dataflow architecture follows the philosophy of letting data drive control, with early works from MIT [2] [3]. With regular compute and memory patterns in AI tensors, dataflow architecture builds massively parallel compute arrays to maximize the computational density and minimize the control overhead. 

Another line of research to exploit DLP for AI workloads targets the von Neumann bottleneck, envisioned by John Backus as early as 1978 [4]. These solutions move the computation closer to the memory (e.g., in/near-memory/storage processing) by attaching additional compute logic next to the memory blocks, unlocking massive DLP on the already wide enough memory blocks.

The Third Axis: Value-Level Parallelism

Though Flynn’s taxonomy, with dimensions of instructions and data, has been followed for decades, there are untouched landscapes. While CLP and DLP focus on concurrency and parallelism, neither asks the next question about the content of the data: can the patterns in data values benefit the computation efficiency? VLP is value-centric and the third axis in this regard, i.e., it targets computational redundancy inherent to the data patterns of workloads. It recognizes that when identical values flow through a pipeline, the arithmetic becomes deterministic and, therefore, avoidable. Consequently, we move from executing every instruction and data to computing only each unique data value.

Origins for GEMM

Carat (Pan, San Miguel, Wu — ASPLOS ’24) [5] is the paper that coined VLP and materialized it in hardware architecture. The insight is simple. As deep learning inference moves to larger batches and lower precisions (e.g., FP8 being the de-facto data format in DeepSeek v3), the number of unique values shrinks rapidly while the frequency of each grows. Here, we give an example. For a scalar-vector multiplication for an arbitrary scale weight w and 1k UINT4 inputs, conventional hardware would compute 1k multiplications for the weight w and each UINT4 vector element. Looking closely, there are only 16 unique products, i.e., 0 x w, 1 x w, 2 x w, …, 15 x w. Thus, conventional hardware would compute 1k/16=64 times more than needed.

Figure 1. Overview of VLP for scalar-vector multiplication.

Figure 1 above outlines how VLP is constructed in Carat. In Figure 1 (a), VLP consists of value reuse, which accumulates the weight w over time, each accumulation result, called a partial product, is used to compute the next partial product. Then each input just subscribes to the proper partial product as the correct output. To materialize the subscription, we leverage temporal coding, often seen in the brain, which generates a spike at the cycle indexed by the data value. For example, a data valued 8 will generate a spike at cycle 8, as shown in Figure 1 (b). Therefore, there exists a temporal correspondence between the spike and the accumulated partial product. Each input subscribes to their correct output in parallel, giving the rise to value-level parallelism. The scheduling unit is no longer the instruction or the array element; it is the unique product value, made available to many input consumers via temporal coding. Given this formulation, we see that lower precision produces fewer unique values, while larger batches create more inputs to share the unique values.

Generalizing Beyond

So far, VLP in Carat targets GEMM optimization for large-batch, low-precision, symmetric-format use cases. However, these assumptions may no longer hold in more recent LLM workloads: the batch size is small (e.g., 8~16) to ensure real-time response, the data formats are asymmetric (e.g., INT4-FP16) to minimize the memory footprint of the weight and KV cache, and the nonlinear operations are heavy and complicated (e.g., softmax, GELU, SiLU) to ensure high accuracy.

Mugi (Price, Vellaisamy, Shen, Wu — ASPLOS ’26) [6] is a follow-up work that closes the gap and generalizes VLP for both linear and nonlinear operations for broader AI workloads. Figure 2 shows VLP for elementwise nonlinear operations that can be done through a four-phase pipeline on input floating-point numbers with a sign (S), mantissa (M) and exponent (E). The first phase is input approximation, which converts wider inputs to narrower bits without sacrificing the LLM accuracy too much. The inputs to nonlinear operations are always in higher precision (e.g., BF16, FP16, or FP32) in AI workloads than model weights. The approximation to narrower bits ensures a shorter temporal signal for high throughput. The second phase is value reuse with opportunities from large GEMM shapes in LLMs. Unlike value reuse in Carat accumulating the partial product, value reuse in Mugi loads the precomputed nonlinear results, where higher accuracy is allocated to more critical inputs. The third phase performs temporal subscription on the mantissa bits (M) of the inputs. For each input, the selected output corresponds to the nonlinear results with the same mantissa but different exponents (E). Finally, the fourth phase performs temporal subscription on the exponent bits of the inputs. For each input, the selected output corresponds to the correct mantissa and exponent.

Figure 2. Overview of VLP for elementwise nonlinear operations.

Mugi essentially cascades VLP to construct high dimensionality in the value space to compute nonlinear operations. The resulting architecture unifies the datapath for both linear and nonlinear operations, leading to savings in silicon area.

What Makes VLP Different

Conventional architectures pay arithmetic costs to process every instruction and data element while advanced techniques (e.g., memoization, tabulation) leverage computation reuse and pay memory costs to store past results and refer back to them when needed. VLP pays for neither: it minimizes both arithmetic and memory access, instead spending its silicon budget on value delivery, i.e., the network and temporal converters that route unique results to many input consumers in parallel. The type of computation fundamentally changes to something new: a form of temporal subscription.

Future Opportunities and Open Questions

In its current form, VLP relies on temporal coding, which is actually inspired from how the brain works. Though the community has focused predominantly on deep learning, VLP opens up a different research direction: what are potential synergies between neuromorphic and classical computing in computer architecture? Looking beyond, VLP raises several questions to answer in the AI era. 

• Where does VLP stop paying off? Though Carat and Mugi work for varying batch sizes, both of them now are designed for low precision to create more opportunities for value reuse. There is presumably a design space with high precision and low value redundancy. It is essential to understand the mechanism to exploit VLP for such scenarios and quantify the potential gain.
• Is VLP an ISA-level concept or an accelerator-level one? Both Carat and Mugi are accelerator designs. A real-world question is whether VLP can inform CPU and GPU microarchitecture. What would a VLP-based tensor instruction look like? Could it be a drop-in replacement of tensor cores with better efficiency?
• What should the software stack look like? VLP for nonlinear involves approximation, which naturally introduces inaccuracy to the task. This falls back to the question of approximate computing, but in the context of new hardware primitives. We probably shall build a co-design framework to deploy VLP under approximation errors.
• Can VLP live with sparsity? Sparse computation has been a major optimization since the start of deep learning, and more opportunities are emerging from weight, KV-cache spanning across the bit level, value level, block level and even request level. It is meaningful to study how VLP synergizes with such use cases.
• How does VLP interact with memory? Despite efforts in computation, memory stays at the core of AI. A natural question is whether we can optimize the memory system with VLP, or more broadly, value-centric computing. There have been associative memory-based AI accelerators, and whether there could be VLP-based alternatives?

Final Thoughts

Architecture research is all about how to compute faster and more efficiently. Control-level parallelism has let us argue about IPC and pipelines for thirty years. Data-level parallelism has let us argue about FLOPS and dataflow for fifteen. Value-level parallelism, the third axis, now shows promise for emerging AI workloads (thanks to Carat and Mugi) and paves the way for exciting synergies between neuromorphic and classical computing. Here’s hoping one day computer architects see the value in it.

About the authors:

Di Wu is an assistant professor at the University of Central Florida. 

Zhewen Pan is a PhD candidate at the University of Wisconsin–Madison. 

Joshua San Miguel is an associate professor at the University of Wisconsin–Madison.

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.

Editor’s Note: this post is a republication of CRA-I post available at: https://cra.org/industry/2026/04/27/how-ai-will-reshape-computer-systems-by-2035-a-jeffersonian-dinner-in-san-francisco-about-our-10000x-future/

CRA-Industry (CRA-I) recently continued its series of intimate Industry Salon Gatherings, bringing together leaders to discuss the long-term trajectory of our field. Our latest session, organized by Mark D. Hill (University of Wisconsin-Madison & CRA) and CRA-I, took place on April 16, 2026 at the historic University Club of San Francisco and was sponsored by Laude Institute, which had just announced an ambitious and exciting slate of new research “AI moonshot” awards.

The evening featured a high-level conversation among 20 participants, co-hosted by Dave Patterson (UC Berkeley/Google) and Jeff Dean (Google AI). The Salon tackled a fundamental question: “What will computer systems look like in 2035, and how will they be designed?” The participants were researchers and leaders from West Coast academic institutions and technology companies, big and small. As the table below shows, the group was diverse in multiple dimensions, including career stage, with expertise centering on computer architecture but extending to software systems, AI models, and design methodology and tools.

Following the “Jeffersonian” dinner format, the evening was designed to forge deep connections and brainstorm visionary ideas. To ensure a frank and pre-competitive dialogue, the event operated under the Chatham House Rule, allowing for candid exchange while protecting the anonymity of the participants’ specific contributions.

The three-hour (!) conversation explored the intersection of architecture, software, AI, and future design methodologies. Here we highlight some key observations and conjectures made by Salon participants:

• We are in the midst of an AI revolution that appears to be even more impactful than the introduction of microprocessors, PCs, Internet, or smartphones.
• To drive future change, we must focus on metrics such as improving “intelligence” per Watt for efficiency and more AI tokens processed at fixed user-perceived latency for more “intelligence.”
• One lively topic was centered on the future of interfaces and abstractions that have been essential for humans to build complex systems. We explored two related questions: whether abstractions will continue to matter in the AI era, and, if they do, whether those abstractions must remain human-interpretable, allowing human/AI teams to advance the field together. The general view was that abstractions will continue to play an important role, not only for humans, but also helping AI systems to reason and coordinate. However, for communication and reasoning among agents, these abstractions need not be interpretable to humans, and may evolve beyond human comprehension. At the same time, there remains a need for human-interpretable abstractions to enable oversight, intervention and guidance by humans.
• We conjecture that in five years 10,000x more AI inference will be done worldwide, with these gains hypothetically coming from multiplicative progress of  50x in AI algorithms, 50x in system/hardware optimization/specialization, and 4x from further data center growth.
• We expect 50x AI algorithm progress for three reasons. First, Transformers have sparked a rapid series of AI inventions since the original paper in 2017, and the area is still ripe. There has been a clear trend in increased data and compute efficiency in training large models. Second, there is an existence proof that we can do much better since humans learning from birth to early adulthood are able to use 1,000x less input data than today’s largest ML models, suggesting that much more data-efficient learning algorithms are still possible.Third, deep analysis to determine what aspects of current AI technology are necessary for current levels of intelligence may reveal much more efficient methods for obtaining the same or better results.
• We expect 50x system/hardware progress from two trends. First, increased hardware specialization will lead to major improvements in efficiency. Second, AI to automate hardware design will enable much faster and lower-cost creation of this specialized hardware. AI is already greatly impacting the system/hardware design process. We expect many design flows to be accelerated or altered. For example, can Large Language Models iterate with improving formal tools and specification methods to “hill climb” design spaces, and can formal verification be accelerated by customized hardware? Moreover, AI is having a fundamental impact on software developers. We conjecture that future developers will write little code directly. Rather, they will manage teams of AI agents. And this in turn could dramatically accelerate software development for specialized hardware. How do we prepare students and professionals for this world?
• We expect a substantial increase in global data center capacity (perhaps 4x over the next five years), but recognize that non-technical forces are at play here. Expansion will be relatively larger if companies focus on scale out more than the above innovation opportunities. However, expansion could be much less due to community “techlash.”
• We discussed energy trends, including that solar was now significantly cheaper than other energy sources for new capacity, and that battery prices continued to fall, making solar+batteries a viable way of powering new datacenters and other energy needs.  We also discussed other new sources of clean energy that are not yet commercially viable but might be in the next five years, such as fusion.
• Finally, acknowledging “tech-lash” brings us to opportunities and challenges that AI brings to society. Much of the public views AI as a potential disruption in their lives, fearing the negative more than embracing the positive. They may currently be correct. It is our job to ensure that we develop and encourage the societally- beneficial aspects of AI, and we discussed education and healthcare as two domains with considerable early positive benefits and enormous further potential.  We also recognized negative aspects of AI usage in areas like easing the creation of misinformation and cyberattacks, and many expressed concern about society’s capacity to absorb substantial job disruption in short time scales.  We conjecture that within the next few years, AI policy will be a major election factor. How do we make a public AI debate substantive? How do we ensure policymakers can make informed decisions about AI, so that we can sensibly regulate some of the negative consequences of AI without stifling the positive uses? As AI changes our world, how does that change university teaching, life-long learning, and job retraining? How does it alter university and industry research? Three hours are insufficient to answer these societal questions.

In their Turing Award lecture in 2018, Hennessy and Patterson asserted that we were beginning a Golden Age for computer architecture. The subsequent decade has shown them to be prescient.

This San Francisco gathering reinforced the value of bringing industry and academia together to look beyond the immediate product cycle. As noted by the organizers, the insights gained here will help shape the CRA roadmap for supporting the computing research ecosystem over the next decade.

As we went around the table to get everyone’s last comments, many mentioned how much they enjoyed the conversation and would love to do it again. Impressively, four of the invited leaders had to fly to San Francisco for the event and everyone stayed until the official end of the three-plus-hour reception and dinner. The feedback was overwhelmingly positive. One participant noted that it was “valuable to hear directly from the leaders of our community [about] their perspectives on the role of AI—both in how we design computers and the projected compute demand driving that design.” Another shared that the evening was “tremendously valuable for my own thinking on where the computing industry is and should be going, and for sharing thoughts to hopefully influence how others view technology advancement and its societal implications.”

If you are interested in participating in or hosting future CRA-I Salon Gatherings, please sign up for our mailing list or contact Helen Wright (hwright@cra.org).

Salon Participants

About the Authors:

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.

This article continues (and concludes) the discussion on the proceedings of DPC-4, covering the remaining four contestants and a summary of the trends observed in all eight prefetchers presented in the championship. Similar to Part I, we focus on how each prefetch algorithm functions, and why it is effective. Finer implementation details can be obtained from the workshop papers or the source code.

BertiGO (Simranjit Singh, University of Murcia; Agustín Navarro Torres, University of Zaragoza; Alberto Ros (University of Murcia

Motivation

When evaluating the baseline prefetcher configuration, the authors noted that Berti frequently issues redundant prefetch requests for lines already prefetched or present in the cache. Also, using only the PC provides very limited context for pattern recognition, limiting the prediction capabilities of Berti. Furthermore, Pythia is found to generate a lot of useless prefetches for some workloads, which pollutes the L2 cache and wastes memory bandwidth.

Idea

1. A Region-Based Bit-Map Filter is added, which is a fully associative structure storing the prefetched and accessed cache lines per region, in the form of a bit-vector. For regions tracked by the filter, having the M-th bit set in the bitmap implies that we drop all prefetch requests for the M-th cache line inside the region.
2. In addition to using PC, the authors propose using a hash (shifted XOR) of the last 4 PCs with the current PC, to index the Berti tables with additional context.
3. Set-Dueling is added to Pythia: instead of using the default policy to issue prefetches, 5 different policies are introduced, including a No-Prefetch policy that disables Pythia. All 5 policies are enabled for a 10M-instruction tournament, at the end of which the policy with the lowest miss rate is chosen for the rest of execution.
4. An Adaptive Next Line (ANeLin) is added to the LLC, which uses a sampling cache to track the demand misses and insert next-line prefetches. A heuristic mechanism is used to track useful and useless prefetches globally and per-PC. ANeLin can be disabled if the ratio of useful to useless prefetches drops below a threshold.

Why It Works

Adding a Bit-Map Filter eliminates redundant and useless prefetches. Using PC history adds context from the program flow while learning memory accesses with minimal overhead. Disabling Pythia and Next Line prefetching when they do not generate enough useful prefetches solves the problem of cache pollution due to wasteful prefetching. This is especially useful in the constrained bandwidth and multicore scenarios where data and memory need to be shared judiciously for optimal performance.

Entangling Data Prefetcher (Agustín Navarro Torres, Universidad de Zaragoza;  Simranjit Singh, University of Murcia; Biswabandan Panda, IIT Bombay; Alberto Ros, University of Murcia)

Motivation

Comparing Berti with other state-of-art prefetchers, the authors identify a SPEC2017 workload where Berti achieves negligible performance gain over no-prefetch baseline. Profiling this trace reveals that it consists of long-reuse strides (stride accesses separated by 2K-cycle interval) and zero-strides (consecutive accesses to the same cache line). Berti cannot issue zero-delta prefetches, and even though prefetches are correctly issued for long-reuse deltas, they get evicted before the cache line gets accessed. T-SKID, a Time Skipping Prefetcher is built on top of a standard PC-Stride prefetcher, but decouples the PC that triggers a prefetch (TriggerPC) from the PC that trains the predictor(TargetPC). This allows it to prefetch long-reuse and zero stride patterns. However, the underlying stride prefetcher limits its scope to constant stride instead of complex delta patterns predicted easily by Berti.

Idea

EDP is proposed as a VA-based L1D prefetcher. It gets trained and triggered on cache misses or prefetch hits (cache hit on a prefetched line). For every TargetPC, it records the fill latency of the demand access or prefetch request. It then searches the global PC history for the most recent PC that was observed more than (current cycle – fill latency) cycles ago – this is the TriggerPC which could have triggered a timely prefetch for TargetPC. This ‘Entangling Pair’ of PCs is added to the Entangling Table, that stores the set of TargetPCs for a given TriggerPC. EDP also looks at the address history of each TargetPC to calculate the list of timely deltas (similar to Berti) and stores them with the current address in a Delta Table indexed by TargetPC. To issue prefetches, the TriggerPC is used to obtain one or more TargetPC, which are used to obtain address and deltas for timely prefetch. The prefetches calculated in this way are passed through a Bloom Filter to drop redundant requests, and then placed in a Proxy Prefetch Queue (PPQ) where the prefetch request waits till slots open up in the demand read queue. If there is no space in the latter, prefetch requests are not issued. Pythia is implemented at L2, with a throttling mechanism at LLC that tracks each core’s requests and sets the EDP aggressiveness.

Why It Works

Using a different PC to trigger prefetches allows EDP to successfully prefetch zero and long reuse delta patterns for its target PC. Filtering out redundant prefetches reduces contention for resources. Using a dedicated PPQ for prefetch requests prevents prefetches from competing with critical loads for resources. The LLC throttling mechanism helps evenly distribute resources in the multi-core scenario.

Composite Prefetching with Bandits (Charles Block, Pedro Palacios, Abraham Farrell, Gerasimos Gerogiannis, Josep Torrellas, University of Illinois at Urbana-Champaign)

Motivation

The authors point out that the current state-of-the-art prefetchers try to optimize low-level metrics such as accuracy, timeliness and coverage. The system performance (IPC) depends on these factors, but can have variable sensitivity to each of them depending on the workload and program phase. Furthermore, a single prefetcher is generally insufficient to deliver the best performance for a diverse set of workloads – industrial processors generally deploy a composite prefetcher consisting of multiple prefetch engines.

Idea

A Multi-Armed Bandit is a Reinforcement Learning agent that chooses the best action (arm) to maximize the reward function value. Inspired by this, a Micro-Armed Bandit (MAB) is used to prefetch at L2C. Each ‘arm’ consists of different configurations for 5 state-of-the-art prefetchers-

• Next Line, Spatial Memory Streaming, Best Offset Prefetcher: Can be turned ON or OFF
• Stride, Stream prefetchers: Degree can be tuned to control aggressiveness

A bloom filter is implemented to prevent issuing redundant prefetches. Each arm is used for a fixed time period (bandit step) after which the reward generated by it is evaluated by the agent. This is evaluated against the rewards generated previously to calculate which arm to use next. The total IPC of the core is used as a reward function for the MAB.

To optimize multi-core performance, another agent called ‘µMama’ is added at the system level, using the geometric mean of IPCs across all cores as a reward function. At each timestep, it decides whether to allow the cores to pursue their independent actions, or to force them into joint actions which have a record of increasing the µMama reward.

Why It Works

Using Reinforcement Learning to directly maximize the system performance ensures that the prefetcher dynamically re-configures itself with execution to improve IPC. The caveat is that this now becomes a search space problem – the arms of the bandit need to be diverse enough to support different kinds of workloads, in order to deliver the best performance.

Global Berti (Gilead Posluns, Mark Jeffrey; University of Toronto)

Motivation

Berti is a state-of-the-art prefetcher that detects Streaming patterns, i.e., consistent delta values between accesses by the same PC. Practical workloads however, often exhibit Spatial patterns identified by consistent delta values between accesses by different PCs. In the absence of streaming patterns, prefetching based on spatial patterns could alleviate the efficacy of Berti.

Idea

Global Berti detects spatial patterns using Berti’s existing structures – the History Table conventionally stores within a row, the addresses of all the lines accessed by a particular PC, in FIFO order. When a streaming pattern cannot be detected, local training is useless and Global Berti looks at the most recent address for all PCs to detect spatial patterns (global training). Berti’s Delta Table holds the row delta values for the same PC; Global Berti stores the global deltas (across PCs) in the same table, adding a local bit to differentiate between streaming and spatial training.

Why It Works

By itself, Berti is quite effective at detecting and covering streaming patterns. Adding the capability to detect spatial patterns in the absence of streaming patterns increases Global Berti’s coverage and therefore, the overall performance. As expected, the highest speedup over Berti is obtained in SPEC2017 and Graph workloads that are dominated by irregular accesses which require spatial prefetching. On the other hand, AI workloads containing mostly streaming patterns see a much lesser speedup.

General Trends

Although the major focus of almost all DPC-4 submissions is to overcome the limitations of the high-performing Berti/Pythia baseline, they highlight several key trends in data prefetching research:

• Prefetching across Physical Page Boundaries: Issuing page-crossing prefetches is extremely useful for AI workloads since they are dominated by streaming accesses. This is leveraged by most submissions to gain an edge over the baseline prefetcher configuration.
• Preventing Redundant Prefetches: Quite a few papers also combat excessive prefetching and resource contention through advanced throttling, priority, and filtering mechanisms.
• Increased System-Level and Multi-Core Awareness: There is a growing emphasis on system-aware solutions to judiciously manage shared resources like memory bandwidth, which is constrained in high-core-count datacenters. This includes core-level fairness throttling (Emender, EDP) and global coordination agents (µMama) to dynamically adjust prefetcher configurations for optimal multi-core performance.
• Expanding Pattern Coverage for Diverse Workloads: Submissions seek to improve coverage beyond simple streaming patterns. This includes detecting spatial patterns across different PCs (Global Berti), and targeting complex patterns like long-reuse and zero-strides (EDP). The adoption of PC history (BertiGO) also provides better context for pattern recognition.
• Shift Towards Adaptive and Composite Designs: Recognizing that a  single prefetcher is insufficient for diverse workloads, the trend moves toward composite prefetchers. This is accompanied by dynamic re-configuration to select the best prefetcher setting at runtime, and adaptive heuristics to tune aggressiveness.

About the Author

Digvijay Singh obtained his Bachelor’s degree from BITS Pilani and his Master’s degree from Texas A&M University where he worked on data prefetching as part of the CAMSIN research group. He currently works as a Silicon Architect in Google’s mobile CPU team.

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.

This article is the first in a two-part series that summarizes the key contributions of 4th Data Prefetching Championship (DPC-4), held in conjunction with the 32nd iteration of HPCA in 2026. While discussing innovative data prefetching techniques presented in this contest, we focus on the functionality of proposed algorithms and also explain why they are effective. Finer implementation details can be found from the papers or the source code.

Implementation Constraints

All prefetchers are evaluated against a baseline configuration that employs: Berti prefetcher (DPC3 winner) at L1D (Level-1 Data cache) and Pythia prefetcher at L2 (Level-2 cache). While there were no constraint on design complexity, upper limits were defined on the storage budget of the prefetchers to ensure the design was practically feasible for implementation. These limits were defined as follows: L1D Prefetcher: 32KB, L2 Prefetcher: 128KB, LLC (Last Level Cache) Prefetcher: 256KB.

Keynotes

The event included two keynote talks. The first keynote, titled “Is Prefetcher Research Still Alive?”, was given by Leeor Peled from Huawei. Leeor discussed the modern relevance of prefetching research, offering a pragmatic philosophy for academic researchers. He argued that the primary objective should not necessarily be to surpass “best-in-class” models – which are often the result of years of ‘engineered’ fine-tuning – but rather to introduce novel, high-potential concepts that invite further optimization. He emphasized that while an individual effort might not immediately surpass the state-of-the-art, a sufficiently “interesting” technique can evolve into a transformative solution through subsequent community-driven iteration.

He suggested two optimizations that can be explored:

1. Building a Semantic Prefetcher that correlates memory accesses with address generating code, i.e., a high-precision version of the Runahead Prefetcher that selectively runs only the code responsible for generating a future address.
2. Training neural networks to identify deep correlations between memory accesses, potentially unlocking the ability to predict complex, non-linear patterns that remain invisible to current heuristic-based logic.

The following issues can (and should) be addressed to build better prefetchers:

• Generalizing complex patterns, e.g. pointer chasing loads
• Accurately choosing memory access with high correlation for better training
• Prefetching to the appropriate cache level to optimize for timeliness
• Throttling prefetches for fairness amongst multiple cores
• Using LLMs to process memory traces instead of text sequences

The second keynote, titled “Data Prefetching: A Datacenter Perspective”, was given by Akanksha J. from Google.  Addressing the memory bottleneck problem in modern datacenters (40% of the CPU cycles are spent idling for memory responses) Akanksha highlighted that cloud environments are characterized by massive multi-threading and incessant context switching. In these scenarios, a single thread may migrate across multiple cores, while each core rotates through a vast “plethora” of applications. The Google workloads utilized in DPC-4 are a better representation of this reality, and are primarily frontend-bound. Without a sophisticated instruction prefetcher to streamline code delivery, the underlying bottlenecks in data prefetching remain obscured and impossible to solve. She also analyzed structural failures of current prefetching solutions, identifying these primary aspects:

1. Current design philosophy focuses on “tuning for the common case,” resulting in hard-coded heuristic values—such as fixed confidence thresholds and prefetch degrees—that are taped out into non-programmable silicon. While these “black boxes” are meticulously engineered to squeeze every drop of performance from SPEC workloads, they lack the flexibility required for the high heterogeneity of datacenter tasks. Consequently, these resource-hungry techniques often penalize cloud performance rather than enhancing it.
2. If we disable hardware prefetchers entirely and rely on software to insert prefetches, we miss out on critical opportunities to utilize valuable information about system states (coherence, timeliness, cache hits/misses) that improves prefetching. Akanksha proposed a shift towards “Software-Defined Prefetching,” a paradigm that transcends current ISA limitations. In this model, the software layer dynamically selects which code segments to target and determines the optimal hardware prefetcher to activate for peak accuracy. Simultaneously, the hardware leverages real-time system state data to maximize coverage.

Furthermore, Akanksha advocated for evaluating all prefetching techniques within constrained-bandwidth environments, arguing that such stress tests better reflect the realities of modern compute environments.

Now, on to prefetcher designs themselves.

Virtual Inter-Page Prefetcher (Ho Je Lee, Won Woo Ro; Yonsei University)

Motivation

• Analyzing the baseline prefetecher configuration, the authors observed that the L2 Prefetcher (Pythia) is more effective than the L1 Prefetcher (Berti) in reducing Misses Per Kilo Instructions (MPKI) for the Last Level Cache (LLC).
• Since Pythia operates in the Physical Address (PA) space, it is not feasible to let it issue prefetches across page boundaries, as incorrect physical page access poses a security risk.
• A roofline study shows that there is significant performance to be gained when Pythia is allowed to issue page-cross prefetches in the PA space. This advantage amplifies when it is granted visibility of the Virtual Address (VA) space, preventing incorrect page accesses.

Idea

VIP is implemented at L1 level,  but issues prefetches to the L2. It gets trained on L1 Misses by reading the {PC, VA} information off the packets sent to L1 MSHR. These are written to the VIP Stride Table that calculates the observed stride for a particular PC and stores it. If a stride value is repeated, the confidence gets incremented. Otherwise it gets reset. The confidence value determines the prefetch degree.

Why It Works

The implemented VIP configuration is a simple yet elegant solution to gain performance over the baseline by supplementing the existing Berti and Pythia prefetchers with cross-page prefetches (note that the DPC-3 version of Berti operates in the PA space and cannot issue prefetches across page boundaries). As expected, the stride prefetcher boosts AI workloads with sequential accesses of large data structures that span across pages. The typical CPU workloads such as SPEC see a moderate gain; the control-flow dominated Google workloads have a marginal slowdown since they rarely have uninterrupted streams.

Signature Pattern Prediction and Access-Map Prefetcher (Maccoy Merrell, Lei Wang, Paul Gratz, Stavros Kalafatis; Texas A&M University)

Motivation

Access Map Pattern Matching (AMPM) and Signature Path Prefetching (SPP) are both considered state-of-the-art prefetching techniques; while SPP is sensitive to the order of memory accesses, AMPM is resistant to OoO execution. However, AMPM relies heavily on stored patterns for each region and  is unable to issue prefetches for new regions or when the observed accesses deviate from expectations. SPP excels at this and can even make predictions from its issued prefetches.

Idea

Implemented at L2 level, a Region Table (RT) tracks all access maps (as bit-vectors) on a per-region basis. Upon a memory access, an N-bit portion from the respective access map is used to index a Pattern Table (PT). The PT outputs the most frequently occurring N-bit pattern as a prefetch candidate, which can be used to speculatively index the PT. Similar to SPP, speculative prefetching continues till the overall confidence drops below a threshold. The RT access map indicates the recently accessed cache lines and filters out redundant prefetches.

Why It Works

The authors have identified the complementary nature of SPP and AMPM, and have combined them effectively to utilize the OoO resistance of AMPM with the Speculative mechanism of SPP. Additionally, numerous throttling mechanisms are implemented which consider pattern usefulness as well as global metrics such as DRAM bandwidth and overall usefulness to drop prefetches and set prefetch degree. SPPAM is implemented at L2C with Berti (the MICRO version which operates in the VA space) at L1D and Bingo at LLC. Similar to the previous paper, the cross-page stream information is passed to SPPAM from L1D.

Emender (Jiajie Chen, Tingji Zhang, Xiaoyi Liu, Xuefeng Zhang, Peng Qu, Youhui Zhang; Tsinghua University)

Motivation

An evaluation of different combinations of state-of-the-art prefetchers shows that VBerti (L1D) and Pythia (L2) is the highest performing combination. Here, VBerti refers to the MICRO version of Berti that operates in the VA space, allowing it to issue page-crossing prefetches. It is observed that this optimal prefetcher combination issues too many prefetch requests that fill the prefetch queue quickly, which leads to useful prefetches getting dropped. A second-order effect of a full prefetch queue is the excessive usage of L1D to Memory bandwidth that can delay critical loads.

Idea

Four key features are added to tackle the problem of over-prefetching in the VBerti+Pythia configuration:

1. Pending Target Buffer is added to sort all issued prefetches by confidence, which helps prioritize useful prefetches between different PCs.
2. Cuckoo Filter is added which tracks the VAs already present in the cache to prevent redundant prefetches. This structure is chosen due to its O(1) query time, high accuracy and zero false negatives.
3. Dynamic Confidence Threshold is added which increases with the cache miss rate, throttling low-confidence prefetches.
4. A Fairness-based Throttling scheme is implemented across cores, which tracks the useless prefetches per-core at L3 and stops the core with the most useless prefetches from prefetching.

Why It Works

The authors identify problematic areas in the baseline Berti+Pythia system and propose features to effectively address them. The best performance improvement comes from the Cuckoo Filter for single-core and Fairness Throttling for multi-core configuration. Since Emender provides the least gain for limited bandwidth configuration, it would be interesting to look at the accuracy data.

sBerti (Jiapeng Zhou, Ben Chen, Kunlin Li, Yun Chen; HKUST, Guangzhou)

Motivation

When profiling the DPC4 workloads on the given baseline prefetcher configuration (Berti + Pythia), the authors observed a high L1D miss rate in the AI-ML and Google workloads. A deeper analysis of the traces indicated that most of these misses occurred when the access stream moved across the 4KB physical page boundary, which happens frequently in these workloads. The version of Berti used in the baseline does not issue prefetches across page boundaries, and thus, a stride prefetcher can help.

Idea

A decoupled Smart Stride Prefetcher is added at L1D, which operates on the VA space and can  therefore track memory access streams across page boundaries. It is trained using a Smart Stride Table (SST), which is indexed by a hash of the PC, and subtracts the lastVA from the current VA to calculate the delta value. If the absolute value of delta is a multiple of the stored stride, the confidence is updated; this also provides resistance to out-of-order execution. Prefetches are issued if this confidence is greater than a static threshold. The lookahead is tuned via a heuristic which is incremented upon observing late prefetches and decremented by timely prefetches. A Recent Prefetch Table stores the recently issued prefetches to track their timeliness and filter duplicate prefetches between Berti and Smart Stride engines.

Why It Works

The addition of a decoupled stride prefetcher gives sBerti the ability to issue prefetches across physical page boundaries, reducing the “Cold-start Penalty” of Berti. The heuristic based dynamic distance adjustment helps tune the aggressiveness at runtime, allowing longer lookahead for AI-ML workloads dominated by streaming accesses. The final sBerti configuration (Stride + Berti at L1D, Pythia at L2) delivers the best performance in a full bandwidth scenario, where the stride engine can prefetch further ahead.

We will overview the rest of the prefetchers in part 2 of this post.

About the Author

Digvijay Singh received his Bachelor’s degree from BITS Pilani and his Master’s degree from Texas A&M University where he worked on data prefetching as part of the CAMSIN research group. He currently works as a Silicon Architect in Google’s mobile CPU team.

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.

Hybrid continuous-discrete-variable (CV-DV) quantum computing combines oscillators and qubits to tackle problems that are difficult for either model alone, from bosonic simulation to quantum error correction. At ASPLOS 2026, our tutorial introduced the foundations, compilation stack, benchmarking methods, and programming tools behind this emerging architecture model. In this blog post, we overview the key elements of our tutorial. 

Tutorial website: https://cvdv.ncsu.edu/resources/asplos-tutorial/

Foundations

We began with the foundations of hybrid CV-DV quantum computing, introducing the physical model, mathematical language, and programming abstractions behind qubit-oscillator systems. Many leading quantum platforms naturally combine qubits with oscillator modes, such as cavities, vibrational modes, or photonic fields. Rather than treating oscillators as auxiliary hardware, hybrid CV-DV computing views their large Hilbert spaces as a computational resource.

The tutorial covered core representations of CV states in both Fock space and phase space, along with the key operators and gate families that support universal CV-DV computation. A central message was that hybrid systems are not simply “qubits plus extra hardware,” but a distinct computational model with their own instruction sets, abstractions, and compilation challenges. We showed how familiar qubit concepts such as Pauli and Clifford structure extend into the oscillator setting through displacement operations, squeezing, quadratic Hamiltonians, beamsplitters, and controlled hybrid interactions.

We also discussed why this matters from a computer architecture perspective. Hybrid CV-DV systems introduce new instruction set architectures (ISAs), abstract machine models (AMMs), and compilation choices that help separate hardware details from software design. Depending on the platform and compiler stack, the same computation may be expressed in phase-space language, Fock-space language, or a mixed qubit-oscillator representation.

To ground these ideas, we highlighted emerging algorithmic primitives and applications where hybrid systems may offer advantages, including oscillator-mediated entangling gates, state-transfer protocols, Hamiltonian simulation, bosonic quantum error correction, vibronic dynamics, and sensing. We closed the session by surveying two leading implementation pathways, superconducting circuit QED and trapped-ion systems, and discussing the distinct control and connectivity tradeoffs they expose. A comprehensive tutorial on the foundations of hybrid CV-DV quantum processors is available here.

Compilation

We also presented Strategies and Tools to Compile CV-DV Quantum Circuits. We began by emphasizing why Hamiltonian simulation is a central application and one of the most promising directions for hybrid continuous-variable and discrete-variable (CV-DV) quantum systems. CV systems can naturally represent continuous degrees of freedom, while DV systems provide strong control and interaction structures. Together, they enable important applications in areas such as quantum chemistry and materials science. However, a key challenge lies in decomposing the time-evolution operator e^{-iHt} into a sequence of executable quantum gates. This transformation is fundamentally a compilation problem, bridging high-level quantum algorithms and low-level hardware. As such, compilers play a critical role in hybrid quantum systems.

We then focused on the dominant approach today: symbolic compilation. In particular, we discussed two early CV-DV Hamiltonian simulation compilers from Chen et al., ISCA’25 and Decker et al., QCE’25. The core idea is to avoid direct matrix-based computation and instead leverage the algebraic structure of operators for rule-based decomposition. Techniques such as Trotter-Suzuki product formulas, the Baker–Campbell–Hausdorff (BCH) expansion, and bosonic commutation relations are used to gradually break down complex Hamiltonians into hardware-executable primitive gates. This process is typically implemented through rule matching and recursive rewriting, where expressions are repeatedly transformed until only supported base gates remain. While this approach avoids the exponential blowup of high-dimensional matrices, it introduces tradeoffs between approximation error and resource overhead.

Finally, we analyzed the limitations of current compilers and outlined future research directions. Key challenges include limited gate sets and decomposition rules, the tradeoff between accuracy and resource cost, hardware connectivity constraints, and insufficient optimization flexibility. To address these issues, we highlighted the need for improved programmability, richer native gate support, more accurate cost models, and optimizations that exploit algebraic properties such as commutativity. We also presented the Genesis compiler from Chen et al., ISCA’25 as an end-to-end solution example, including typical use cases and code snippets. Genesis employs a multi-level intermediate representation (IR) and a full compilation pipeline to automatically translate Hamiltonians into limited hardware connectivity physical circuits, demonstrating a systematic and extensible compilation framework for hybrid CV-DV quantum computing.

Benchmark and Circuit Simulator

We also presented HyQBench by Mohapatra et al., an open-source benchmark suite implemented in Bosonic Qiskit and QuTiP. HyQBench covers eight representative hybrid circuits spanning three abstraction levels: primitives, algorithms, and applications. These include cat state generation, GKP state preparation, CV-to-DV state transfer, CV-DV QFT, CV-DV VQE, CV-QAOA, Jaynes-Cummings-Hubbard (JCH) Hamiltonian simulation, and Shor’s algorithm.

One key takeaway is that hybrid architectures can reduce hardware resources dramatically for some workloads. For example, simulating a 3-site JCH model in a DV-only encoding requires 9 qubits and 393 CNOT gates, whereas a hybrid implementation uses only 3 qumodes, 3 qubits, and 8 gates. This kind of reduction highlights why benchmarking hybrid systems requires more than simply counting qubits.

To support this, we introduced a feature map tailored to hybrid systems. In addition to standard structural metrics such as gate counts, circuit depth, and qubit/qumode counts, we proposed three CV-DV-specific metrics: Wigner negativity as a proxy for non-classicality and classical simulation hardness, truncation cost to quantify population near the Fock cutoff, and maximum energy. These metrics help separate workloads with very different simulation and execution behavior. For example, JCH simulation remains relatively close to Gaussian behavior, while CV-QAOA and Shor’s algorithm exhibit higher Wigner negativity and are harder to simulate classically.

We also discussed early hardware validation. A cat-state preparation benchmark was executed on Sandia National Laboratories’ QSCOUT trapped-ion platform and achieved a fidelity of 0.71. HyQBench was further used to calibrate conditional displacement gates on the same platform, reinforcing the need for standardized benchmark suites that support both evaluation and device calibration. The full paper is available at https://arxiv.org/abs/2603.04398.

To lower the barrier to entry for this area, we also developed HyQSim, a browser-based hybrid CV-DV circuit simulator that requires no installation. HyQSim supports drag-and-drop circuit construction, arbitrary Fock cutoffs, and built-in visualization through Wigner plots, Fock-state amplitudes, and Bloch sphere views. It is available at https://cvdv.ncsu.edu/resources/simulator/, and the code is hosted at https://github.com/shubdeepmohapatra01/HyQSim/.

Programming

Finally, we discussed programming support for hybrid CV-DV systems. Quantum programming languages and frameworks have developed many important ideas over the years, including linear quantum types for enforcing the no-cloning theorem, automatic uncomputation of ancilla qubits, and dynamic lifting of classical variables for mid-circuit measurement. Hybrid quantum computing introduces an additional requirement: heterogeneous quantum registers containing both qubits and qumodes.

To address this challenge, we developed Hybridlane, a CV-DV quantum programming framework built on PennyLane. By extending PennyLane, Hybridlane inherits a broad library of qubit algorithms, gates, and compilation routines while remaining familiar to existing users. Hybridlane tracks wire types automatically through symbolic circuit analysis and type inference, enabling scalable circuit construction, platform independence, and integration with downstream compilation flows.

The tutorial concluded with example workflows using Hybridlane. In one example, we reused an existing PennyLane quantum phase estimation template for a CV-DV Hamiltonian simulation and then lowered it through symbolic compilation to a gate sequence executable on the Bosonic Qiskit backend. In another, we demonstrated a cross-platform workflow in which a conditional displacement gate was calibrated in simulation and then compiled for execution on Sandia’s QSCOUT trapped-ion platform. Together, these examples showed how hybrid quantum software can begin to support the same define-simulate-execute workflow that has become standard in mature qubit SDKs.

We hope Hybridlane helps enable a broader ecosystem of reusable software and research for hybrid quantum computing. It is available at https://github.com/pnnl/hybridlane.

Closing

Hybrid CV-DV computing sits at the intersection of quantum hardware, computer architecture, compilation, and programming systems. We hope this tutorial helps make the area more accessible to researchers across architecture, systems, programming languages, and quantum information, and we invite readers to explore the tutorial materials, benchmarks, and tools linked above.

About the Authors

Yuan Liu is an Assistant Professor of Electrical & Computer Engineering and Computer Science at North Carolina State University. Prior to joining the NC State faculty, he was a postdoctoral researcher at the Massachusetts Institute of Technology. His research interests lie at the intersection of quantum computing, quantum engineering, quantum algorithms/architectures and applications.

Zihan Chen is a Ph.D. student in computer systems at Rutgers University, advised by Prof. Eddy Z. Zhang. His research focuses on compiler and system-level techniques, as well as parallel computing, to enhance the efficiency, programmability, scalability, and fault tolerance of emerging quantum computing systems.

Shubdeep Mohapatra is a Ph.D. candidate in Computer Engineering at NC State University, advised by Prof. Huiyang Zhou and Prof. Yuan Liu. His research focuses on quantum error characterization, mitigation, and benchmarking, aimed at improving the reliability and fault tolerance of near-term quantum computing systems.

Jim Furches is a post-masters research associate at Pacific Northwest National Laboratory. His current research interests are in quantum benchmarking, algorithms, and quantum programming and compilation.

Zheng (Eddy) Zhang is a Professor in the Department of Computer Science at Rutgers University. Her research focuses on full-stack compiler and programming systems for quantum computing. She studies how to better coordinate quantum applications, programming languages, intermediate representations, compilation, pulse-level control, and hardware architecture to improve the performance, usability, and scalability of quantum systems.

Huiyang Zhou is a Professor of Electrical and Computer Engineering at North Carolina State University. His current research interests include GPU architecture, processor security, and quantum computing.

Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.