Pith. sign in

REVIEW 3 major objections 6 minor 5 cited by

SwizzlePerf: Hardware-Aware LLMs for GPU Kernel Performance Optimization

T0 review · 3 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read SwizzlePerf shows an LLM with explicit hardware context can match a two-week expert GPU optimization in under five minutes.

desk verdict A useful empirical study of LLM-guided swizzling that is undermined by an internal contradiction in its baseline comparison; worth refereeing after the authors fix that. read the letter →

arxiv 2508.20258 v1 pith:DARY36CQ submitted 2025-08-27 cs.DC cs.AI

Arya Tschand , Muhammad Awad , Ryan Swann , Kesavan Ramakrishnan , Jeffrey Ma , Keith Lowery , Ganesh Dasika , Vijay Janapa Reddi This is my paper · ORCID
classification cs.DCcs.AI
keywords swizzlingGPUkerneloptimizationhardware-awareLLML2cachelocalityprogramIDremappingautotuningdisaggregatedarchitectureperformanceengineering
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

SwizzlePerf sets out to show that the missing ingredient in LLM-based GPU kernel optimization is hardware-awareness: an LLM given profiled bottleneck metrics, machine geometry, and scheduling policy can generate spatial optimizations that search-based, runtime-only methods miss. The paper's central result is that this workflow reproduces an expert-designed GEMM swizzling pattern in under five minutes and improves L2 cache hit rate by an average of 23.9% across ten ML and scientific kernels, with end-to-end speedups up to 2.06x on nine of them. If true, it makes a class of cache-locality optimizations that currently take expert weeks a matter of minutes, and points to bottleneck-specific metrics as the right objective for autonomous performance engineering.

What carries the argument

The central mechanism is the PID swizzle: a small formula that remaps GPU workgroup program IDs so that cooperating tiles land on the same accelerator die, or XCD, and share its L2 cache. Around that, the workflow is a closed loop: a structured prompt bundles a short memory-locality summary, the architecture's XCD count and cache sizes, the default round-robin block-scheduling policy, and a history of prior attempts; the LLM must critique those attempts and emit a new swizzling formula; the kernel is compiled, checked for correctness, and profiled for L2 hit rate; the best candidate by that metric is retained and fed back into the next round. The L2 hit rate is the load-bearing objective because it is a stable, low-noise signal that directly reflects whether the remapping improved cache locality.

What would settle it

Enumerate all bijective PID remappings for a small kernel (e.g., a 16-block grid), measure end-to-end runtime and L2 hit rate for each; the central claim predicts higher hit rate tracks with faster runtime, so any mapping with higher hit rate but slower runtime would refute the proxy claim.

Watch

Extended reading notes

Core claim

On its own terms, the paper discovers that explicit hardware-awareness—profiled bottleneck metrics, cache and XCD geometry, default block-scheduling policy, and a history of previous attempts—is the missing ingredient that lets an LLM generate correct, generalizable swizzling formulas. Swizzling here means remapping GPU workgroup program IDs so that cooperating tiles are co-located on the same accelerator die and reuse the same L2 cache instead of thrashing across dies. The paper reports that this lifts L2 hit rate by 23.9% on average (up to 70%), pushes four kernels to near 100% hit rate, and translates to up to 2.06x end-to-end speedup on nine of ten kernels, while hardware-unaware context and an unfiltered architecture dump both fail to yield speedups.

Load-bearing premise

The load-bearing premise is that improving the profiler's L2 hit rate by remapping program IDs reliably means the kernel will run faster end to end, with no hidden penalty from uneven work distribution or power management.

Editorial extensions

If this is right

  • Automating swizzling removes a two-week manual step in kernel tuning: for any kernel with predictable memory access, the loop can propose a hardware-specific remapping in minutes.
  • Optimizing for a stable bottleneck metric instead of noisy runtime should make LLM-driven performance engineering converge in fewer iterations, since the search is narrowed to transformations that move that metric.
  • The generated patterns are not one-off hacks: ablations show the L2 hit-rate advantage persists across growing problem sizes for layernorm, Smith-Waterman, and stencil kernels.
  • A practical agent would need to choose its underlying LLM per kernel, because the paper finds different models succeed on different kernels and reasoning-tuned models do not always win.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper: the same loop could target other stable bottleneck signals, such as DRAM bandwidth utilization or instruction-stall rates, to automate layout or scheduling transformations; the paper only demonstrates the cache-locality case.
  • Beyond the paper: the ceiling-division edge case in the generated GEMM formula suggests the LLM composes new logic rather than retrieving a known snippet; a natural stress test is to check bijectivity and correctness of generated mappings across arbitrary grid sizes and XCD counts.
  • Beyond the paper: the power-efficiency discussion implies that the same remappings should cut off-chip traffic and therefore energy per instruction; measuring energy directly on the generated kernels would test that corollary.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. SwizzlePerf is an LLM-driven optimization loop that generates swizzling patterns, i.e., remappings of GPU workgroup program IDs, targeting L2 cache locality on AMD MI300X's disaggregated XCD architecture. The system augments the open-source IntelliPerf framework with hardware context, rocprofv3 bottleneck metrics, and an iterative history buffer, selecting candidates by L2 hit rate while validating correctness. The paper reports reproducing an expert GEMM swizzling pattern in under five minutes, and on ten ML/science kernels achieving speedups on 9/10 kernels, up to 2.06x, with average 23.9% L2 hit-rate improvement and up to 70% on individual kernels. It claims that hardware-unaware and hardware-overload baselines never produce speedups, which establishes the necessity of curated hardware-aware context.

Significance. If the empirical results hold, SwizzlePerf is a useful step toward automating hardware-specific spatial optimizations with LLMs. The paper has several concrete strengths: ground-truth correctness validation, a diverse kernel suite spanning ML and scientific workloads, ablations across problem sizes and across three LLMs, and a concrete expert-engineered GEMM pattern that the system rediscovers. The use of L2 hit rate as a bottleneck signal and the candidate-selection loop are well-motivated, and reporting speedups alongside the proxy metric gives independent evidence. The main weakness is that the central comparative claim against baselines is internally inconsistent, so the paper needs revision before the necessity of hardware-aware context can be accepted as stated.

major comments (3)
  1. [Section 4 and Appendix A.4] The claim that the hardware-unaware and hardware-overload baselines 'never give a speedup' is directly contradicted by Appendix A.4, which reports that the hardware-overload optimization loop 'achieves strong speedups' on the transpose kernel at M=N=32768 and can achieve up to 70% higher L2 hit rate than SwizzlePerf. The appendix explains that these bitwise patterns are overfit and 'often fail correctness,' but that does not establish that no hardware-overload run produced a valid, speedup-producing configuration. Please provide a per-configuration accounting of which baseline runs passed correctness validation and their measured runtimes, or narrow the necessity claim from 'hardware-awareness' to 'curated hardware-aware context.'
  2. [Section 4 and Figure 2] The aggregate claims (speedups on 9/10 kernels, average 1.29x, up to 2.06x, average 23.9% L2 hit-rate improvement) are not backed by a per-kernel numeric table. The text does not identify which kernel failed to achieve a speedup, the exact problem sizes for each kernel, or the correctness status and L2/runtime values for every baseline configuration. Figure 2 is described in prose but is not legible in the text version. Please add a table with per-kernel results and describe the measurement methodology, including number of repetitions, variance, and how runtime was measured relative to rocprofv3.
  3. [Section 3, step (4) and Section 4] Because the loop selects candidates by L2 hit rate, the reported L2 hit-rate improvements are partly by construction, and the independent evidence must come from end-to-end runtime speedups. Please state explicitly whether the quoted speedups come from the same kernel selected by L2 hit rate, and report the correlation between L2 hit rate and runtime across candidates. The statement that 'L2 hit rate directly reflects whether cache-aware remapping is successful' is too strong: a remapping could improve the L2 hit rate while introducing load imbalance or serialization, so runtime distributions are needed to support the proxy claim.
minor comments (6)
  1. [Abstract and Appendix A.2] The paper says SwizzlePerf generates 'the same' expert GEMM swizzling pattern, but Appendix A.2 also notes that the generated code contains a ceiling-division edge case absent from the expert version. Please clarify what 'functionally identical' means and show the expert pattern for comparison.
  2. [Appendix A.4] The text refers to 'bitwise SHIFT and ADD swizzling,' but Figure 13 shows only a bitwise swap of adjacent bits. Please align the prose with the code or expand the description.
  3. [Appendix A.6] The sentence 'the swizzled kernel raises the L2 hit rate ... consistently outperforms the unswizzled for' appears to be missing a word; it should say 'unswizzled baseline.'
  4. [Figure 2] The legend symbols x and x with a circle are described in the caption but are not mapped to individual kernels. Please annotate the figure or provide a table that identifies which kernels had no L2 effect and which produced broken remappings.
  5. [Section 3, step (2)] The sentence 'IntelliPerf only profiles the output code for the bottleneck metric' is ambiguous, since the SwizzlePerf pipeline also profiles the original code. Please clarify exactly what profiling information is added in the hardware-aware context beyond what IntelliPerf already obtains.
  6. [Appendix A.1] The prompt structure in Figure 3 uses placeholders rather than a full prompt. For reproducibility, please include the complete prompt and output signature in the appendix.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: SwizzlePerf's reported speedups are independently measured end-to-end and validated for correctness, so the L2 hit-rate signal used during search does not force the claimed outcomes by construction.

full rationale

The paper's central claims are empirical, not derived from a fitted model or a self-citation chain. SwizzlePerf uses L2 hit rate as both the optimization signal and one reported outcome, but the headline results are end-to-end kernel speedups (up to 2.06x) and correctness-validated code, which are separate measurements from the selection metric. No parameter is fitted to a subset of data and then renamed as a prediction; no uniqueness theorem is imported from the authors' prior work; and the cited IntelliPerf framework is used as a compile/validate/profile scaffold rather than as the source of the swizzling patterns or the speedup claims. The internal inconsistency between Section 4's claim that baseline hardware-overload 'never give[s] a speedup' and Appendix A.4's report that hardware-overload 'achieves strong speedups' on transpose is a correctness or reporting concern, not a circularity concern, because it does not make SwizzlePerf's outcome equivalent to its inputs. The derivation chain is therefore self-contained: the paper proposes a prompting/selection loop, evaluates it on external kernels, and reports runtime improvements verified against reference implementations.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

No numerical free parameters are fitted; the method is empirical and does not tune constants to data. The load-bearing assumptions are the hardware topology, the L2 hit-rate proxy, the LLM's ability to produce bijective swizzles, and the fairness of the IntelliPerf baseline.

assumptions (4)
  • domain assumption AMD MI300X has multiple XCDs, each with a dedicated L2 cache, and default workgroup scheduling is round-robin across XCDs.
    Section 3 and Appendix A.2; all generated swizzles are built on this topology, which comes from vendor documentation rather than from this paper.
  • domain assumption rocprofv3 L2 hit rate is an accurate, low-noise proxy for spatial locality and the correct optimization objective.
    Section 3 step 2 and Section 4; the paper asserts this but does not validate the proxy against runtime on each kernel or report noise levels.
  • domain assumption The LLM can generate bijective PID remappings from text context, and the compile/validate step catches broken mappings.
    Section 3 steps 3 and 4; Appendix A.4 notes that many overload patterns fail bijectivity, so correctness is checked empirically rather than formally.
  • ad hoc to paper The IntelliPerf baseline is a fair representation of hardware-unaware LLM optimization.
    The paper builds on IntelliPerf and compares against it; if the baseline is weak or under-budgeted, the conclusion that hardware awareness is necessary would be overstated.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SwizzlePerf: Hardware-Aware LLMs for GPU Kernel Performance Optimization." pith.science (2026). https://pith.science/paper/DARY36CQ

@misc{pith2026250820258,
  author       = {Pith},
  title        = {Pith review of: SwizzlePerf: Hardware-Aware LLMs for GPU Kernel Performance Optimization},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DARY36CQ}},
  note         = {Machine review of arXiv:2508.20258}
}
read the original abstract

Large language models (LLMs) have shown progress in GPU kernel performance engineering using inefficient search-based methods that optimize around runtime. Any existing approach lacks a key characteristic that human performance engineers rely on for near-optimal utilization -- hardware-awareness. By leveraging the workload's specific memory access patterns, architecture specifications, filtered profiling logs, and reflections on historical performance, we can make software-level optimizations that are tailored to the underlying hardware. SwizzlePerf automatically generates spatial optimizations for GPU kernels on disaggregated architectures by giving LLMs explicit hardware-awareness. For a GEMM kernel, SwizzlePerf takes less than 5 minutes to generate the same hardware-specific optimal swizzling pattern that took expert performance engineers 2 weeks to find. On a suite of 10 diverse ML and Science kernels, SwizzlePerf can generate swizzling patterns for 9 of the kernels that achieve up to a 2.06x speedup and 70% improvement in L2 hit rate. This work is the first of many steps toward systematically creating hardware-aware LLM performance engineering agents.

Figures

Figures reproduced from arXiv: 2508.20258 by the authors.

Figure 1
Figure 1. SwizzlePerf methodology and example swizzling outcome. (a) The optimization loop begins with the CodeGen LLM call input, which integrates the parsed context of bottleneck metrics, GPU characteristics, and the scheduling policy. The LLM reflects on past bottlenecks and proposes a new swizzling formula in the CodeGen LLM call output. (b) SwizzlePerf generates this pattern for GEMM on a 4-XCD architecture. The swizzlin… view at source ↗
Figure 2
Figure 2. L2 hit rate improvements and speedups from swizzling patterns on 10 kernels. The gray bars denote the original L2 hit rate of unswizzled code, blue bars show the L2 hit rate improvement from the SwizzlePerf-generated swizzling patterns, and orange and green bars show baselines. The red line denotes the corresponding SwizzlePerf end-to-end kernel speedup. SwizzlePerf achieves speedups on 9 out of 10 kernels of up to … view at source ↗
Figure 3
Figure 3. Structure of hardware-awareness input prompt to LLM. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (12 more)
Figure 4
Figure 4. Figure 4: Structure of DSPy output signature [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: GEMM swizzling strategy and equivalent SwizzlePerf-generated swizzling pattern. [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: SwizzlePerf-generated swizzling pattern for layer normalization kernel. [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: SwizzlePerf-generated swizzling pattern for softmax kernel. [PITH_FULL_IMAGE:figures/full_fig_p006_7.png]
Figure 8
Figure 8. Figure 8: SwizzlePerf-generated swizzling pattern for finite-difference time-domain kernel. [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]
Figure 9
Figure 9. Figure 9: SwizzlePerf-generated swizzling pattern for stencil 2D kernel. [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 10
Figure 10. Figure 10: SwizzlePerf-generated swizzling pattern for transpose kernel. [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]
Figure 11
Figure 11. Figure 11: Hardware-aware SwizzlePerf swizzling code for transpose kernel. [PITH_FULL_IMAGE:figures/full_fig_p008_11.png]
Figure 12
Figure 12. Figure 12: Hardware-unaware swizzling code for transpose kernel. [PITH_FULL_IMAGE:figures/full_fig_p008_12.png]
Figure 14
Figure 14. Figure 14: Progression plots for GEMM, Stencil 2D, SpMV, Softmax, and LayerNorm kernels. [PITH_FULL_IMAGE:figures/full_fig_p009_14.png]
Figure 15
Figure 15. Figure 15: L2 cache hit rate vs. problem size for the three kernels. A.7 Ablation Study: Evaluating Hardware-Awareness with Different LLMs In [PITH_FULL_IMAGE:figures/full_fig_p010_15.png]
Figure 16
Figure 16. Figure 16: L2 hit rate of SwizzlePerf-generated patterns with 3 different LLMs. [PITH_FULL_IMAGE:figures/full_fig_p011_16.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 5 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. JAXBench: Benchmarking Autonomous TPU Kernel Optimization

    cs.AI 2026-05 conditional novelty 6.0 of 10

    On a new 50-workload TPU benchmark (JAXBench), documentation-conditioned LLM agents reach 37.3% per-sample correctness and 1.28-1.36x geomean speedups over XLA, with curated context beating model scale.

  2. Kernel Foundry: A Diagnosis-driven Evolutionary Kernel Optimizer with Multi-Experts

    cs.NE 2026-05 unverdicted novelty 6.0 of 10

    Kernel Foundry improves GPU kernel correctness and performance on KernelBench via expert-guided evolutionary search with diagnostic feedback and an experience library, reaching 100% correctness on Level 2.

  3. LEO: Tracing GPU Stall Root Causes via Cross-Vendor Backward Slicing

    cs.DC 2026-04 unverdicted novelty 6.0 of 10

    LEO performs cross-vendor backward slicing from stalled GPU instructions to attribute root causes to source code, enabling optimizations that produce geometric-mean speedups of 1.73-1.82x on 21 workloads.

  4. CUDA-L2: Surpassing cuBLAS Performance for Matrix Multiplication through Reinforcement Learning

    cs.LG 2025-12 conditional novelty 5.0 of 10

    CUDA-L2's RL-generated HGEMM kernels are claimed to beat cuBLASLt autotuning by 11.4-15.9% on 1000 A100 shapes, though no independent artifacts are supplied.

  5. Towards Automated Kernel Generation in the Era of LLMs

    cs.LG 2026-01 conditional novelty 4.0 of 10

    A structured survey of LLM-based and agentic approaches for GPU kernel generation, plus a catalog of datasets and benchmarks for the field.

Reference graph

Works this paper leans on

28 extracted references · 13 canonical work pages · cited by 5 Pith papers

  1. [1]

    Learning to optimize halide with tree search and random programs

    Andrew Adams, Sung Hee Ma, Luke Anderson, Jonathan Ragan-Kelley, et al. Learning to optimize halide with tree search and random programs. ACM Transactions on Graphics (TOG), 38(4):121:1–121:12, 2019. URL https://halide-lang.org/papers/halide_ autoscheduler_2019.pdf

    work page 2019

  2. [2]

    Gqa: Training generalized multi-query transformer models from multi-head checkpoints

    Joshua Ainslie, James Lee-Thorp, Michiel De Jong, Yury Zemlyanskiy, Federico Lebrón, and Sumit Sanghai. Gqa: Training generalized multi-query transformer models from multi-head checkpoints. arXiv preprint arXiv:2305.13245, 2023

    arXiv 2023

  3. [3]

    Heterogeneous-computing interface for portability (HIP)

    AMD. Heterogeneous-computing interface for portability (HIP). https://rocm.docs.amd. com/projects/HIP/en/latest/index.html, . [Online; accessed 06-August-2025]

    work page 2025

  4. [4]

    ROCprofiler-SDK: Application profiling, tracing, and performance analysis

    AMD. ROCprofiler-SDK: Application profiling, tracing, and performance analysis. https: //github.com/ROCm/rocprofiler-sdk, . [Online; accessed 06-August-2025]

    work page 2025

  5. [5]

    Gpu kernel scientist: An llm-driven framework for iterative kernel optimization

    Martin Andrews and Sam Witteveen. Gpu kernel scientist: An llm-driven framework for iterative kernel optimization. arXiv preprint arXiv:2506.20807, 2025

    arXiv 2025

  6. [6]

    Opentuner: An extensible framework for program autotuning

    Jason Ansel, Shoaib Kamil, Kalyan Veeramachaneni, Jonathan Ragan-Kelley, Jeffrey Bosboom, Una-May O’Reilly, and Saman Amarasinghe. Opentuner: An extensible framework for program autotuning. In Proceedings of the 23rd International Conference on Parallel Architectures and Compilation Techniques (PACT), 2014. doi: 10.1145/2628071.2628092

    arXiv 2014

  7. [7]

    Intelliperf: LLM-powered autonomous GPU performance engineer, July 2025

    Muhammad Awad, Cole Ramos, and Keith Lowery. Intelliperf: LLM-powered autonomous GPU performance engineer, July 2025. URL https://github.com/AMDResearch/ intelliperf

    work page 2025

  8. [8]

    Kevin: Multi-turn rl for generating cuda kernels

    Carlo Baronio, Pietro Marsella, Ben Pan, Simon Guo, and Silas Alberti. Kevin: Multi-turn rl for generating cuda kernels. arXiv preprint arXiv:2507.11948, 2025

    arXiv 2025

Show all 28 references
  1. [9]

    Yan, Ziheng Jiang, Thierry Moreau, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy

    Tianqi Chen, Lianmin Zheng, Eddie Q. Yan, Ziheng Jiang, Thierry Moreau, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy. Learning to optimize tensor programs. In Advances in Neural Information Processing Systems (NeurIPS), 2018. URL https://arxiv.org/abs/ 1805.08166

    2018 arXiv

  2. [10]

    Multi-head attention: Collaborate instead of concatenate

    Jean-Baptiste Cordonnier, Andreas Loukas, and Martin Jaggi. Multi-head attention: Collaborate instead of concatenate. arXiv preprint arXiv:2006.16362, 2020

    2006 arXiv

  3. [11]

    Flashattention: Fast and memory-efficient exact attention with io-awareness

    Tri Dao, Dan Fu, Stefano Ermon, Atri Rudra, and Christopher Ré. Flashattention: Fast and memory-efficient exact attention with io-awareness. Advances in neural information processing systems, 35:16344–16359, 2022

    2022

  4. [12]

    Flex attention: A pro- gramming model for generating optimized attention kernels

    Juechu Dong, Boyuan Feng, Driss Guessous, Yanbo Liang, and Horace He. Flex attention: A pro- gramming model for generating optimized attention kernels. arXiv preprint arXiv:2412.05496, 2024

    2024 arXiv

  5. [13]

    Matteo Frigo and Steven G. Johnson. The design and implementation of fftw3. Proceedings of the IEEE, 93(2):216–231, 2005

    2005

  6. [14]

    An integrated gpu power and performance model

    Sunpyo Hong and Hyesoon Kim. An integrated gpu power and performance model. In Proceedings of the 37th annual international symposium on Computer architecture , pages 280–289, 2010

    2010

  7. [15]

    Demonstrate-search-predict: Composing retrieval and language models for knowledge-intensive NLP

    Omar Khattab, Keshav Santhanam, Xiang Lisa Li, David Hall, Percy Liang, Christopher Potts, and Matei Zaharia. Demonstrate-search-predict: Composing retrieval and language models for knowledge-intensive NLP. arXiv preprint arXiv:2212.14024, 2022. doi: 10.48550/arXiv.2212. 14024

    2022 doi arXiv

  8. [16]

    Joshi, Hanna Moazam, Heather Miller, Matei Zaharia, and Christopher Potts

    Omar Khattab, Arnav Singhvi, Paridhi Maheshwari, Zhiyuan Zhang, Keshav Santhanam, Sri Vardhamanan, Saiful Haq, Ashutosh Sharma, Thomas T. Joshi, Hanna Moazam, Heather Miller, Matei Zaharia, and Christopher Potts. DSPy: Compiling declarative language model calls into self-impro...

    2024

  9. [17]

    Cuda-l1: Improving cuda optimization via contrastive reinforcement learning

    Xiaoya Li, Xiaofei Sun, Albert Wang, Jiwei Li, and Chris Shum. Cuda-l1: Improving cuda optimization via contrastive reinforcement learning. arXiv preprint arXiv:2507.14111, 2025

    2025 arXiv

  10. [18]

    Competition-level code generation with alphacode

    Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Rémi Leblond, Tom Eccles, James Keeling, Felix Gimeno, Agustin Dal Lago, et al. Competition-level code generation with alphacode. Science, 378(6624):1092–1097, 2022

    2022

  11. [19]

    Rigorous evaluation of computer processors with statistical model checking

    Filip Mazurek, Arya Tschand, Yu Wang, Miroslav Pajic, and Daniel Sorin. Rigorous evaluation of computer processors with statistical model checking. In Proceedings of the 56th Annual IEEE/ACM International Symposium on Microarchitecture, pages 1242–1254, 2023

    2023

  12. [20]

    Kernelbench: Can llms write efficient gpu kernels? arXiv preprint arXiv:2502.10517, 2025

    Anne Ouyang, Simon Guo, Simran Arora, Alex L Zhang, William Hu, Christopher Ré, and Azalia Mirhoseini. Kernelbench: Can llms write efficient gpu kernels? arXiv preprint arXiv:2502.10517, 2025

    2025 arXiv

  13. [21]

    Quarch: A question-answering dataset for ai agents in computer architecture

    Shvetank Prakash, Andrew Cheng, Jason Yik, Arya Tschand, Radhika Ghosal, Ikechukwu Uchendu, Jessica Quaye, Jeffrey Ma, Shreyas Grampurohit, Sofia Giannuzzi, et al. Quarch: A question-answering dataset for ai agents in computer architecture. IEEE Computer Architecture Letters, 2025

    2025

  14. [22]

    Lean attention: Hardware-aware scalable attention mechanism for the decode-phase of transformers

    Rya Sanovar, Srikant Bharadwaj, Renee St Amant, Victor Rühle, and Saravan Rajmohan. Lean attention: Hardware-aware scalable attention mechanism for the decode-phase of transformers. arXiv preprint arXiv:2405.10480, 2024

    2024 arXiv

  15. [23]

    Learning performance-improving code edits

    Alexander Shypula, Aman Madaan, Yimeng Zeng, Uri Alon, Jacob Gardner, Milad Hashemi, Graham Neubig, Parthasarathy Ranganathan, Osbert Bastani, and Amir Yazdanbakhsh. Learning performance-improving code edits. arXiv preprint arXiv:2302.07867, 2023

    2023 arXiv

  16. [24]

    11.1 amd instincttm mi300 series modular chiplet package–hpc and ai accelerator for exa-class systems

    Alan Smith, Eric Chapman, Chintan Patel, Raja Swaminathan, John Wuu, Tyrone Huang, Wonjun Jung, Alexander Kaganov, Hugh McIntyre, and Ramon Mangaser. 11.1 amd instincttm mi300 series modular chiplet package–hpc and ai accelerator for exa-class systems. In 2024 IEEE Internation...

    2024

  17. [25]

    Mlperf power: Benchmarking the energy efficiency of machine learning systems from mi- crowatts to megawatts for sustainable ai

    Arya Tschand, Arun Tejusve Raghunath Rajan, Sachin Idgunji, Anirban Ghosh, Jeremy Holle- man, Csaba Kiraly, Pawan Ambalkar, Ritika Borkar, Ramesh Chukka, Trevor Cockrell, et al. Mlperf power: Benchmarking the energy efficiency of machine learning systems from mi- crowatts to m...

    arXiv

  18. [26]

    Measuring energy and power with papi

    Vincent M Weaver, Matt Johnson, Kiran Kasichayanula, James Ralph, Piotr Luszczek, Dan Terpstra, and Shirley Moore. Measuring energy and power with papi. In 2012 41st international conference on parallel processing workshops, pages 262–268. IEEE, 2012

    2012

  19. [27]

    Clint Whaley, Antoine Petitet, and Jack J

    R. Clint Whaley, Antoine Petitet, and Jack J. Dongarra. Automated empirical optimizations of software and the atlas project. Parallel Computing, 27(1–2):3–35, 2001

    2001

  20. [28]

    Gonzalez, Ion Stoica, and Koushik Sen

    Lianmin Zheng, Chengfan Gao, Eddie Ye, Junru Shao, Ziheng Zhuo, Tianqi Chen, Yida Wang, Zhi Zhou, Jared Roesch, Arvind Krishnamurthy, Luis Ceze, Zhihao Jia, Joseph E. Gonzalez, Ion Stoica, and Koushik Sen. Ansor: Generating high-performance tensor programs for deep learning. I...

    2020

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.