Pith. sign in

REVIEW 4 major objections 5 minor 37 references

Triton kernels match expert-tuned C++ on a custom AI accelerator.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-04 00:42 UTC pith:4KZQ25LB

load-bearing objection A credible, substantial engineering report on bringing Triton to a non-GPU accelerator; the performance parity claim rests on internal, normalized evidence, so treat the headline numbers as plausible but not proven. the 4 major comments →

arxiv 2608.00325 v1 pith:4KZQ25LB submitted 2026-07-31 cs.PL

Triton for MTIA: Bridging the Programming Model Gaps for Custom AI Accelerators

Haishan Zhu , Domi Yan , Michael Levesque-Dion , Changxu Zhang , Mitch Gamburg , Kirsten Lee , Giancarlo Colmenares , Aditya Bhagwat
show 32 more authors
Arnab De Markus Le Roux Victor Perez Carrasco Xin Tong Will Cromar Simran Barnwal Andrew Uderian Blaine Burton Rister Jordan Fix Jazlyn Li Zejun Huang Lite Ye Nan Zhang Xinchen Guo Andiry Xu Michael Roberts Kunming Ho Site Cao Suryadev Sahadevan Rajesh Tristan Trouwen Mike Tsai Jake Lee Wayne Su Yuhan Chen Xiaolong Xie David Eklov Aaron Barnes Max Bremer Adam Belay Shintaro Iwasaki Roman Levenstein Ajit Mathews
This is my paper
classification cs.PL
keywords Tritondomain-specific languagecustom AI acceleratorcompiler backendTorchInductorsoftware pipeliningcircular bufferkernel portability
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

This paper tries to establish that a high-level, block-oriented kernel language designed for GPUs can be retargeted to a custom AI accelerator whose hardware model is fundamentally different. On that accelerator, kernels issue asynchronous commands to fixed-function units, manage on-chip memory through FIFO-like circular buffers, and schedule commands explicitly—none of which resembles GPU execution. The authors build a new Triton compiler backend that handles these differences, adapt the graph compiler's code generation to the accelerator, and add a few small language extensions that expose architecture-specific features such as processing-element identity queries and cross-PE reductions. They report that Triton kernels are competitive with expert-tuned C++ for GEMM, fused attention, and long-tail operators, and that manual and compiler-generated Triton kernels have been deployed in production across roughly 60 model types, covering 50% of layers and 47% of non-GEMM runtime. If true, this means kernel developers could write one portable high-level kernel and get near-hand-tuned performance, instead of rewriting kernels for every new chip.

Core claim

On the paper's own terms, the central discovery is that Triton—a block-level language in which operations act on statically shaped tensors with explicit loads and stores—is expressive enough to cover the programming model of a custom accelerator like MTIA-2i, provided the compiler fills the architectural gaps. A new backend lowers Triton IR through a middle end that maps operations to the chip's fixed-function units (dot-product, SIMD, reduction, and memory-layout engines) and to DMA transfers wherever memory access is structured, then applies backend passes for tensor bufferization onto circular buffers, software pipelining with greedy buffer sizing and pointer management, instruction distr

What carries the argument

The circular buffer (CB) is the central mechanism: a FIFO-like on-chip memory region with read and write pointers that hardware uses to enforce data dependencies. Combined with the compiler's static analysis of Triton's statically shaped tensors, the CB enables asynchronous issue of commands to fixed-function units, pointer adjustment at loop boundaries, and greedy buffer sizing for software pipelining. A second load-bearing mechanism is the structured-memory-access analysis that rewrites tensor-of-pointers into DMA-able descriptors, determining which operations run on fixed-function units versus the RISC-V vector core.

Load-bearing premise

The parity claim depends on the expert-tuned C++ kernels being genuinely strong baselines—measured, tuned, and selected by the same team that built the compiler, with no external benchmark or raw numbers supplied—so if those baselines are not the best achievable, the 'competitive' conclusion may not survive independent comparison.

What would settle it

Run an independent, blind comparison on MTIA-2i silicon: have a separate team hand-tune C++ kernels and the same team (or independent users) write Triton kernels for the same production operator set, then publish per-operator speedups. If the average Triton kernel falls materially below the independent C++ baseline (e.g., more than a few percent on the long-tail suite), the parity claim is falsified.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • If the parity claim holds, a custom accelerator does not need a GPU-style SIMT execution model to benefit from Triton; the block-level abstraction absorbs the difference.
  • Operators written once in Triton can be ported between GPUs and the accelerator with minor changes—11 of 16 kernels ported directly, with fixes for undefined masked-load behavior.
  • Automatic kernel fusion via the graph compiler reaches competitive performance with handwritten kernels, with an average fusion depth of 3.9 operators and a 31% improvement over the handwritten kernels it replaced in one training model.
  • Production coverage can ramp quickly: the number of model types using Triton tripled and the runtime share doubled within a quarter, so high-level DSLs shorten the path from kernel authoring to deployment.
  • The language-extension strategy offers a composable path: baseline Triton remains portable, while MTIA-specific primitives can be used selectively in performance-critical code.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • An implication the paper leaves implicit is that the same compiler-layering approach—shared IR dialects and passes across abstraction levels—could make future accelerator DSLs cheaper to build, since much of the backend work is reusable.
  • The observation that masked loads with unspecified 'other' values behaved differently on GPU and MTIA suggests that Triton's language semantics need to pin down undefined behavior if portability is a core promise; standardizing masked-out element initialization would remove a whole class of porting bugs.
  • If the reported 47% non-GEMM runtime share continues its trajectory, the remaining gap to full coverage is likely to concentrate in kernels with irregular control flow or communication patterns, where compiler inference fails and explicit extensions are needed—so the practical ceiling of DSL coverage may be set by how many such extensions the language absorbs.
  • A testable extension of the approach: apply the same backend strategy to a different custom accelerator with a scratchpad-plus-explicit-DMA model; if a comparable portion of production layers reaches parity with hand-written kernels, the result generalizes beyond this one chip.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper reports on building a Triton compiler backend for Meta's MTIA-2i custom AI accelerator, whose programming model differs from GPUs in execution model, on-chip memory management, and instruction scheduling. The authors describe a four-stage compiler pipeline, optimization passes (software pipelining, RISC-V vectorization, PID-to-PE load balancing), minimal Triton language extensions, and Inductor integration. They evaluate GEMM, FlashAttention, long-tail kernels, and Inductor-generated kernels on MTIA-2i silicon, and report production deployment across roughly 60 model types, covering 50% of layers and 47% of non-GEMM execution time. The central claim is that Triton-MTIA kernels achieve performance competitive with expert-tuned C++ implementations, making Triton a viable high-level interface for custom accelerators.

Significance. If substantiated, this result would be a significant existence proof: a block-based DSL originally designed for GPUs can be retargeted to a custom accelerator with async command issue, FIFO-like circular buffers, and software-managed scheduling, and can reach performance parity with handwritten C++ for a production workload. The paper has several strengths: it gives a concrete account of the compiler architecture and optimization space; it reports silicon measurements rather than simulation or emulation; and Section 8.1 candidly discusses portability failures, including 5 of 16 ported kernels that required rewriting, which adds credibility. The production deployment statistics and Inductor coverage numbers in Table 1 are also useful evidence of engineering impact. However, the manuscript does not include raw performance data, confidence intervals, baseline source/version details, or any independent benchmark, so the main performance-parity claim is currently underdetermined as presented.

major comments (4)
  1. [§7.1, Figs. 6–9; Abstract] The paper's load-bearing claim—that Triton kernels are 'competitive with expert-tuned C++ implementations'—is not supported by the evidence as presented. Fig. 6 shows only percentage-of-roofline with no absolute throughputs, no roofline definition or methodology, and no concrete C++ comparison values. Figs. 7–9 report normalized speedups without raw runtimes, error bars, confidence intervals, or per-configuration distributions, and several bars in Fig. 7 appear below 1.0. Since the compiler, the Triton kernels, the C++ baselines, and the configuration selection were all produced by the same team, the claim is currently unfalsifiable to an external reader. Please provide a table of raw runtimes/throughputs for every configuration, report the exact baseline kernel versions and source code, describe the tuning effort, and include per-configuration distributions (e.g., min/median/max over re
  2. [§7.1.2, Fig. 7] The FlashAttention evaluation normalizes performance to a 'decomposed baseline' lowered to an optimized kernel library, not to an expert-tuned fused C++ attention kernel. The abstract's claim is parity with expert-tuned C++ implementations; speedups over a decomposed implementation may reflect fusion benefits rather than Triton's competitiveness against a strong handwritten fused kernel. Please add a direct comparison against a fused, handwritten C++ attention kernel, with source/version details and a description of how it was tuned.
  3. [§7.1.3, Fig. 8] Aggregating the 17 long-tail kernels by geomean per operator can conceal large individual regressions. The text mentions 'outliers' but neither identifies them nor quantifies how many kernels are slower than the C++ baseline. Provide per-kernel data (e.g., a scatter plot or table), report the range and the count of kernels outside a bounded margin (say ±10% or ±20%), and define 'on par' operationally. Additionally, the claim that Triton accelerates 'kernel development velocity' is asserted but not measured; if the claim is retained, include development-time data or a clearly scoped qualitative justification.
  4. [§7.2.1, Fig. 9] The Inductor-Triton performance evaluation relies on a single layernorm-sigmoid fusion example compared against a single handwritten baseline. There is no confidence interval, no description of how the handwritten baseline was produced or tuned, and no list of the tensor shapes tested. This is too narrow to support the general statement that 'automatic fusion is competitive with handwritten kernels.' Please report multiple operators, raw numbers, and baseline provenance, or else weaken the claim to the specific example shown.
minor comments (5)
  1. [§2.3] Typo: 'Fixed-F unction Units' should be 'Fixed-Function Units'.
  2. [§5.1] The indexing function f(x) uses symbols d and s without defining their types or ranges; please clarify the notation.
  3. [§7.1.1] The caption for Fig. 6 should define what 'roofline' means (e.g., peak DPE throughput, peak memory bandwidth, or a piecewise bound) and state whether the percentages are computed per configuration or averaged.
  4. [§7.3, Figs. 11–12] The production footprint numbers are interesting, but the methodology for counting 'model types', 'layers', and 'non-GEMM execution time' is not fully specified. Please state the counting rules and, if possible, report variance across models or product groups.
  5. [§8.1] The portability discussion would benefit from naming the 16 kernels and, for the 11 directly portable kernels, saying what 'good enough performance' means quantitatively; as written it is qualitative.

Circularity Check

0 steps flagged

No significant circularity: the paper is an empirical engineering report; no derivation step reduces to its own inputs.

full rationale

The paper does not present a mathematical derivation chain whose conclusions are equivalent to assumed inputs. Its load-bearing claims—that a Triton backend for MTIA-2i was built, that generated kernels are competitive with expert-tuned C++, and that Triton reached a production footprint—are supported by measurements and deployment statistics, not by equations fit to the same quantities. The only self-citations are to prior Meta hardware papers ([13], [15]) used to describe the MTIA-2i architecture and an earlier internal DSL (KNYFE); these are architectural inputs and experience context, not load-bearing uniqueness claims or imported ansatze, and Section 2.3 independently restates the relevant architecture. There is no fitted-parameter-called-prediction pattern, no renaming of a known result, and no result forced by self-citation. The evaluation is internal and normalized, so an external reviewer may question whether the C++ baselines are the strongest achievable or whether aggregate figures mask slowdowns; that is an evidence-quality and generalizability concern, not circularity. Accordingly, the score is 0.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 0 invented entities

No numerical free parameters are fitted to data; the engineering choices (block sizes, scheduling policies, language extensions) are design decisions rather than fitted constants. No new physical or mathematical entities are postulated, so the invented-entities ledger is empty. The load-bearing assumptions are about hardware correctness and the representativeness of internal measurements.

axioms (4)
  • domain assumption MTIA-2i exposes the described architecture: 8x8 PE array, FFUs (DPE, SE, RE, MLU, FI), RISC-V cores, circular-buffer local memory, 15 CBs and 384 KB LS.
    The compiler design and evaluation depend on this hardware model (Sections 2.3, 5.3). It is sourced from earlier Meta publications [13,15] and is not independently verified in this paper.
  • domain assumption The performance figures in Section 7 are accurate measurements on MTIA-2i silicon using representative production configurations.
    No raw measurements, error bars, or independent audit are provided; the paper states results but does not release the supporting data.
  • domain assumption The C++ kernels used as baselines are genuinely expert-tuned and representative of the best achievable low-level implementations.
    The parity claim is central to the paper (Sections 7.1.1-7.1.3), but the baselines were selected by the same team that built the Triton backend and no external baseline suite is used.
  • domain assumption Upstream Triton parser and MLIR infrastructure provide correct semantics for the transformations described.
    The compiler reuses the upstream parser and MLIR dialects (Sections 3.2, 2.5); the paper treats these standard tools as reliable without proving their correctness.

pith-pipeline@v1.3.0-alltime-deepseek · 17717 in / 12119 out tokens · 110723 ms · 2026-08-04T00:42:38.610974+00:00 · methodology

0 comments
read the original abstract

The rapid growth in machine learning workloads has fueled the proliferation of custom accelerator architectures. Designed from the ground up, these accelerators often expose programming models that are distinct from GPUs. While hyperscalers and AI chip startups continue to innovate in this space, achieving broad operator coverage to support diverse models remains a major challenge. Additionally, an easy-to-use, high-level kernel programming language is important for rapid iteration of models and kernels. Triton, together with TorchInductor, addresses these issues on GPUs, but its viability on accelerators with different programming models has yet to be established. In this work, we present the first production-scale application of Triton on a custom ML accelerator, MTIA-2i, developed by Meta. To support MTIA-2i, we develop a new compiler backend that targets it, introduce enhancements to TorchInductor code generation, and propose minimal language extensions that expose MTIA-specific architectural features. We demonstrate that Triton-MTIA kernels achieve performance competitive with expert-tuned C++ implementations. Leveraging these development efficiency gains, we successfully deployed manually written and Inductor-generated Triton kernels in production across approximately 60 different model types, accounting for 50% of layers and 47% of non-GEMM execution time for these models. Our results provide compelling evidence that DSLs like Triton can bridge the programming model gaps between ML frameworks, kernels, and custom accelerators, enabling rapid innovation and efficient deployment at scale.

Figures

Figures reproduced from arXiv: 2608.00325 by Aaron Barnes, Adam Belay, Aditya Bhagwat, Ajit Mathews, Andiry Xu, Andrew Uderian, Arnab De, Blaine Burton Rister, Changxu Zhang, David Eklov, Domi Yan, Giancarlo Colmenares, Haishan Zhu, Jake Lee, Jazlyn Li, Jordan Fix, Kirsten Lee, Kunming Ho, Lite Ye, Markus Le Roux, Max Bremer, Michael Levesque-Dion, Michael Roberts, Mike Tsai, Mitch Gamburg, Nan Zhang, Roman Levenstein, Shintaro Iwasaki, Simran Barnwal, Site Cao, Suryadev Sahadevan Rajesh, Tristan Trouwen, Victor Perez Carrasco, Wayne Su, Will Cromar, Xiaolong Xie, Xinchen Guo, Xin Tong, Yuhan Chen, Zejun Huang.

Figure 3
Figure 3. Figure 3: CB abstraction overview. • Dot Product Engine (DPE): Performs General Matrix Multiplication (GEMM) operations. • SIMD Engine (SE): Performs high-performance vector operations: quantization, nonlinearities, and reductions. • Reduction Engine (RE): Accumulates DPE re￾sults; forwards results to neighboring PEs or local SE. • Memory Layout Unit (MLU): Handles memory layout transformations: transpose, concatena… view at source ↗
Figure 1
Figure 1. Figure 1: High-level architecture of MTIA 2i. Debug Systems Machine Timer Interrupt Controller RISC-V (Scalar) RISC-V (Vector) PE Interconnect Fabric Interface (FI) Command Processor Regs LS Mem Memory Layout Unit (MLU) Dot Product Engine (DPE) Reduction Engine (RE) SIMD Engine (SE) [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: PE’s internal organization. kernels for the operators in the model. It further automat￾ically fuses operators to minimize global memory transfers, specializing them to the tensor shapes, data types, and constant values used in the model. Inductor supports several backends, such as Triton, C++, and Halide [29]. 2.3 MTIA Architectural Overview [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: High-level flow of Triton-MTIA Compiler. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Zigzag workload distribution compared with [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: GEMM Triton kernel performance as percent [PITH_FULL_IMAGE:figures/full_fig_p010_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Attention performance normalized to decom [PITH_FULL_IMAGE:figures/full_fig_p010_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Long tail kernel performance compared to C++ [PITH_FULL_IMAGE:figures/full_fig_p010_8.png] view at source ↗
Figure 10
Figure 10. Figure 10: Sub-graph performance of training a recom [PITH_FULL_IMAGE:figures/full_fig_p011_10.png] view at source ↗
Figure 9
Figure 9. Figure 9: Normalized speedup between a fused layernorm [PITH_FULL_IMAGE:figures/full_fig_p011_9.png] view at source ↗
Figure 11
Figure 11. Figure 11: Number of model types Triton deployed to on [PITH_FULL_IMAGE:figures/full_fig_p012_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Triton’s production footprint in models on [PITH_FULL_IMAGE:figures/full_fig_p012_12.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

37 extracted references · 6 linked inside Pith

  1. [1]

    The llama 3 herd of models,

    A. Dubey, A. Jauhri, A. Pandey, A. Kadian, A. Al- Dahle, A. Letman, A. Mathur, A. Schelten, A. Yang, A. Fanet al., “The llama 3 herd of models,”arXiv e-prints, pp. arXiv–2407, 2024

    2024

  2. [2]

    Deep learning recommen- dation model for personalization and recommendation systems,

    M. Naumov, D. Mudigere, H.-J. M. Shi, J. Huang, N. Sundaraman, J. Park, X. Wang, U. Gupta, C.-J. Wu, A. G. Azzoliniet al., “Deep learning recommen- dation model for personalization and recommendation systems,”arXiv preprint arXiv:1906.00091, 2019

    Pith/arXiv arXiv 1906

  3. [3]

    DHEN: A Deep and Hierarchical Ensemble Network for Large- Scale Click-Through Rate Prediction,

    B. Zhang, L. Luo, X. Liu, J. Li, Z. Chen, W. Zhang, X. Wei, Y. Hao, M. Tsang, W. Wanget al., “DHEN: A Deep and Hierarchical Ensemble Network for Large- Scale Click-Through Rate Prediction,”arXiv preprint arXiv:2203.11014, 2022

    Pith/arXiv arXiv 2022

  4. [4]

    Actions speak louder than words: Trillion-parameter sequential transducers for generative recommendations,

    J. Zhai, L. Liao, X. Liu, Y. Wang, R. Li, X. Cao, L. Gao, Z. Gong, F. Gu, M. Heet al., “Actions speak louder than words: Trillion-parameter sequential transducers for generative recommendations,”arXiv preprint arXiv:2402.17152, 2024

    Pith/arXiv arXiv 2024

  5. [5]

    [Online]

    PyTorchTeam,PyTorch Documentation: Core ATen IR, 2024. [Online]. Available: https://docs.pytorch. org/docs/main/torch.compiler ir.html

    2024

  6. [6]

    The Design Process for Google’s Training Chips: TPUv2 and TPUv3,

    T. Norrie, N. Patil, D. H. Yoon, G. Kurian, S. Li, J. Laudon, C. Young, N. Jouppi, and D. Patterson, “The Design Process for Google’s Training Chips: TPUv2 and TPUv3,”IEEE Micro, vol. 41, no. 2, pp. 56–63, 2021. [Online]. Available: https://doi.org/10.1109/MM.2021.3058217

    arXiv 2021

  7. [7]

    Think Fast: A Tensor Streaming Processor (TSP) for Accelerating Deep Learning Workloads,

    D. Abts, J. Ross, J. Sparling, M. Wong- VanHaren, M. Baker, T. Hawkins, A. Bell, J. Thompson, T. Kahsai, G. Kimmell, J. Hwang, R. Leslie-Hurd, M. Bye, E. Creswick, M. Boyd, M. Venigalla, E. Laforge, J. Purdy, P. Kamath, D. Maheshwari, M. Beidler, G. Rosseel, O. Ahmad, G. Gagarin, R. Czekalski, A. Rane, S. Parmar, J. Werner, J. Sproch, A. Macias, and B. Ku...

    arXiv 2020

  8. [8]

    Accelerating Scientific Applica- tions With SambaNova Reconfigurable Dataflow Architecture,

    M. Emani, V. Vishwanath, C. Adams, M. E. Papka, R. Stevens, L. Florescu, S. Jairath, W. Liu, T. Nama, and A. Sujeeth, “Accelerating Scientific Applica- tions With SambaNova Reconfigurable Dataflow Architecture,”Computing in Science & Engineering, vol. 23, no. 2, pp. 114–119, 2021. [Online]. Available: https://doi.org/10.1109/MCSE.2021.3057203

    arXiv 2021

  9. [9]

    Distributed Training of Large Language Models on A WS Trainium,

    X. Fu, Z. Zhang, H. Fan, G. Huang, M. El-Shabani, R. Huang, R. Solanki, F. Wu, R. Diamant, and Y. Wang, “Distributed Training of Large Language Models on A WS Trainium,” inProceedings of the 2024 ACM Symposium on Cloud Computing. Association for Computing Machinery, 2024, pp. 961–976. [Online]. Available: https://doi.org/10. 1145/3698038.3698535

    arXiv 2024

  10. [11]

    Blackhole & TT-Metalium: The Standalone AI Computer and its Programming Model ,

    J. Vasiljevic and D. Capalija, “ Blackhole & TT-Metalium: The Standalone AI Computer and its Programming Model ,” in2024 IEEE Hot Chips 36 Symposium (HCS). IEEE Computer Society, August 2024, pp. 1–30. [Online]. Available: https://doi.org/10.1109/HCS61935.2024.10664810

    arXiv 2024

  11. [12]

    Cerebras Architecture Deep Dive: First Look Inside the HW/SW Co-Design for Deep Learning : Cerebras Systems ,

    S. Lie, “ Cerebras Architecture Deep Dive: First Look Inside the HW/SW Co-Design for Deep Learning : Cerebras Systems ,” in2022 IEEE Hot Chips 34 Symposium (HCS). IEEE Computer Society, August 2022, pp. 1–34. [Online]. Available: https://doi.org/10.1109/HCS55958.2022.9895479

    arXiv 2022

  12. [13]

    Meta’s Second Generation AI Chip: Model-Chip Co-Design and Productionization Experiences,

    J. Coburn, C. Tang, S. A. Asal, N. Agrawal, R. Chinta, H. Dixit, B. Dodds, S. Dwarakapuram, A. Firoozshahian, C. Gao, K. Gondkar, T. Graf, J. Hu, J. Huang, S. Hughes, A. Hutchin, B. Jakka, G. J. Chen, I. Kalyanaraman, A. Kamath, P. Kansal, E. Kazi, R. Levenstein, M. Maddury, A. Mastro, S. Medaiyese, P. Modi, J. Montgomery, S. Nadathur, A. Nagpal, A. Naras...

    arXiv 2025

  13. [14]

    Development repository for the triton language and compiler,

    OpenAI, “Development repository for the triton language and compiler,” 2025. [Online]. Available: https://github.com/triton-lang/triton

    2025

  14. [15]

    MTIA: First Generation Silicon Targeting Meta’s Recommendation Systems,

    A. Firoozshahian, J. Coburn, R. Levenstein, R. Nattoji, A. Kamath, O. Wu, G. Grewal, H. Aepala, B. Jakka, B. Dreyer, A. Hutchin, U. Diril, K. Nair, E. K. Aredestani, M. Schatz, Y. Hao, R. Komuravelli, K. Ho, S. Abu Asal, J. Shajrawi, K. Quinn, N. Sreedhara, P. Kansal, W. Wei, D. Jayaraman, L. Cheng, P. Chopda, E. Wang, A. Bikumandla, A. Karthik Sengottuve...

    arXiv 2023

  15. [16]

    FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning,

    T. Dao, “FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning,” 2023. [Online]. Available: https://arxiv.org/abs/2307. 08691

    2023

  16. [17]

    FlagOpen/FlagGems: An operator library for large language models implemented in the Triton language,

    BAAI FlagOpen Team, “FlagOpen/FlagGems: An operator library for large language models implemented in the Triton language,” 2024. [Online]. Available: https://github.com/FlagOpen/FlagGems

    2024

  17. [18]

    FlexAt- tention: The Flexibility of PyTorch with the Per- formance of FlashAttention,

    D. Guessous, Y. Liang, J. Dong, and H. He, “FlexAt- tention: The Flexibility of PyTorch with the Per- formance of FlashAttention,” August 2024. [Online]. Available: https://pytorch.org/blog/flexattention/

    2024

  18. [19]

    gpt-oss-120b & gpt-oss-20b Model Card,

    OpenAI, “gpt-oss-120b & gpt-oss-20b Model Card,”

  19. [20]

    Helion: A High-Level DSL for Performant and Portable ML Kernels,

    PyTorchTeam, “Helion: A High-Level DSL for Performant and Portable ML Kernels,” 2025. [Online]. Available: https://pytorch.org/blog/helion/

    2025

  20. [21]

    [Online]

    JAX Developers,JAX Pallas Documentation, 2024. [Online]. Available: https://docs.jax.dev/en/latest/ pallas/index.html

    2024

  21. [22]

    Tlx - triton low-level language extensions,

    Meta, “Tlx - triton low-level language extensions,”

  22. [23]

    Introduction to Gluon,

    OpenAI, “Introduction to Gluon,” 2025. [Online]. Available: https://github.com/triton-lang/triton/ blob/main/python/tutorials/gluon/01-intro.py

    2025

  23. [24]

    Available: https://github.com/ facebookexperimental/triton/tree/tlx

    [Online]. Available: https://github.com/ facebookexperimental/triton/tree/tlx

  24. [26]

    CuTe DSL,

    Nvidia, “CuTe DSL,” 2025. [Online]. Avail- able: https://docs.nvidia.com/cutlass/media/docs/ pythonDSL/cute dsl.html

    2025

  25. [27]

    A WS Neuron adds support for NKI and NXD for training with JAX,

    A WS, “A WS Neuron adds support for NKI and NXD for training with JAX,” 2024. [Online]. Available: https://aws.amazon.com/about-aws/whats-new/ 2024/09/aws-neuron-nki-nxd-training-jax/

    2024

  26. [28]

    Available: https://arxiv.org/abs/ 2504.17577

    [Online]. Available: https://arxiv.org/abs/ 2504.17577

    Pith/arXiv arXiv

  27. [29]

    cutile, the new/old kid on the block: Python programming models for gpus,

    B. A. Lelbach, “cutile, the new/old kid on the block: Python programming models for gpus,” Talk at SciPy 2025, July 2025. [Online]. Available: https://cfp.scipy.org/scipy2025/talk/PBLESZ/

    2025

  28. [30]

    MLIR: A compiler infrastructure for the end of Moore’s law,

    C. Lattner, M. Amini, U. Bondhugula, A. Cohen, A. Davis, J. Pienaar, R. Riddle, T. Shpeisman, N. Vasilache, and O. Zinenko, “MLIR: A compiler infrastructure for the end of Moore’s law,”arXiv preprint arXiv:2002.11054, 2020. [Online]. Available: https://doi.org/10.48550/arXiv.2002.11054

    Pith/arXiv arXiv doi:10.48550/arxiv.2002.11054 2002

  29. [31]

    PyTorch 2: Faster Machine Learning Through Dynamic Python Bytecode Transformation and Graph Compilation,

    J. Ansel, E. Yang, H. He, N. Gimelshein, A. Jain, M. Voznesensky, B. Bao, P. Bell, D. Berard, E. Burovski, G. Chauhan, A. Chourdia, W. Constable, A. Desmaison, Z. DeVito, E. Ellison, W. Feng, J. Gong, M. Gschwind, B. Hirsh, S. Huang, 14 K. Kalambarkar, L. Kirsch, M. Lazos, M. Lezcano, Y. Liang, J. Liang, Y. Lu, C. K. Luk, B. Maher, Y. Pan, C. Puhrsch, M. ...

    arXiv 2024

  30. [32]

    Halide: a language and compiler for optimizing parallelism, locality, and recomputation in image processing pipelines,

    J. Ragan-Kelley, C. Barnes, A. Adams, S. Paris, F. Durand, and S. Amarasinghe, “Halide: a language and compiler for optimizing parallelism, locality, and recomputation in image processing pipelines,”Acm Sigplan Notices, vol. 48, no. 6, pp. 519–530, 2013

    2013

  31. [33]

    risc-v-spec,

    riscvarchive, “risc-v-spec,” 2025. [Online]. Available: https://github.com/riscvarchive/riscv-v-spec

    2025

  32. [34]

    triton-shared: A shared middle-layer for the Triton Compiler,

    Microsoft, “triton-shared: A shared middle-layer for the Triton Compiler,” 2024. [Online]. Available: https://github.com/microsoft/triton-shared

    2024

  33. [35]

    Software pipelining,

    V. H. Allan, R. B. Jones, R. M. Lee, and S. J. Allan, “Software pipelining,”ACM Comput. Surv., vol. 27, no. 3, pp. 367—-432, Sep. 1995. [Online]. Available: https://doi.org/10.1145/212094.212131

    arXiv 1995

  34. [36]

    Triton: Extern Func- tions Tutorial,

    Triton Developers, “Triton: Extern Func- tions Tutorial,” 2024. [Online]. Avail- able: https://triton-lang.org/main/getting-started/ tutorials/07-extern-functions.html 15

    2024

  35. [37]

    MLIR: Scal- ing Compiler Infrastructure for Domain Specific Computation,

    C. Lattner, M. Amini, U. Bondhugula, A. Cohen, A. Davis, J. Pienaar, R. Riddle, T. Shpeisman, N. Vasilache, and O. Zinenko, “MLIR: Scal- ing Compiler Infrastructure for Domain Specific Computation,” in2021 IEEE/ACM International Symposium on Code Generation and Optimiza- tion (CGO), 2021, pp. 2–14. [Online]. Available: https://doi.org/10.1109/CGO51591.202...

    arXiv 2021

  36. [38]

    Attention is All you Need,

    A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, L. u. Kaiser, and I. Polo- sukhin, “Attention is All you Need,” inAdvances in Neural Information Processing Systems, vol. 30. Curran Associates, Inc., 2017

    2017

  37. [2025]

    Available: https://arxiv.org/abs/ 2508.10925

    [Online]. Available: https://arxiv.org/abs/ 2508.10925

    Pith/arXiv arXiv